A especificação MCP de 2026-07-28 remove as sessões em nível de protocolo, move Tasks e MCP Apps para um framework formal de extensões, endurece as regras de OAuth e deprecia o Dynamic Client Registration em favor dos Client ID Metadata Documents. O PaidSync roda em produção um servidor MCP remoto com 630+ ferramentas de anúncios em 14 plataformas para clientes do Claude e do ChatGPT, e estas são notas de trabalho sobre o que cada mudança significa desse ponto de vista. Nada quebra no primeiro dia; recursos depreciados têm janela mínima de doze meses.
Toda afirmação sobre o protocolo abaixo vem do post oficial de lançamento e do changelog de 2026-07-28, ambos lidos no momento da escrita, em 1 de agosto de 2026. As opiniões são nossas. O post de lançamento coloca números de escala no porquê de esta revisão importar: perto de meio bilhão de downloads de SDK por mês nos principais SDKs, os SDKs de TypeScript e Python cada um com mais de um bilhão de downloads no total, e a Honeycomb relatando que quase 20 por cento das suas consultas interativas mensais agora vêm de agentes. A cobertura do The Register relata os mantenedores chamando-a de a versão mais significativa desde o lançamento do MCP remoto. Do nosso lugar, isso é mais ou menos certo, e boa parte da importância é operacional, não vistosa.
O que mudou em 28 de julho
| Mudança | O que é | Do lugar do operador |
|---|---|---|
| Núcleo stateless | Handshake initialize e Mcp-Session-Id removidos; _meta por requisição carrega versão e capacidades | Balanceamento de carga simples, sem sessões fixas |
| Retomada removida | Streams interrompidos perdem a requisição em andamento; os clientes reenviam | Ferramentas de mutação precisam de chaves de idempotência |
| Extensão Tasks | io.modelcontextprotocol/tasks oficial, baseado em polling, entrada no meio da execução | Operações longas de anúncios deixam de brigar com timeouts do gateway |
| MRTR | Os servidores retornam input_required em vez de chamar o cliente | Perguntas no meio da chamada viram estado retomável |
| Autorização reforçada | Validação de iss da RFC 9207, credenciais atreladas ao emissor | Ataques de mix-up em fluxos de token são fechados |
| DCR depreciado | Client ID Metadata Documents substituem o registro da RFC 7591 | A identidade do cliente passa a ser vinculada ao domínio |
| MCP Apps | Extensão oficial para interface interativa inline | Gráficos e formulários de aprovação na superfície do chat |
| Headers e cache | Mcp-Method/Mcp-Name obrigatórios; ttlMs nos resultados de listas | Política por ferramenta na borda sem analisar o corpo |
| Depreciações | Roots, Sampling, Logging, HTTP+SSE, janela mínima de doze meses | Limpeza com um relógio previsível |
O núcleo stateless e o problema da repetição
A mudança principal: o handshake initialize/notifications/initialized acabou, e o header Mcp-Session-Id também. Cada requisição agora carrega a versão do protocolo, as capacidades do cliente e a identidade do cliente em _meta, e um novo RPC obrigatório server/discover permite aos clientes sondar as capacidades logo de início. As notificações de mudança do servidor para o cliente se consolidam em um único stream opcional subscriptions/listen. O efeito prático que os mantenedores buscam, e que o The Register sublinha, é que qualquer requisição pode cair em qualquer instância do servidor atrás de um balanceador de carga comum, com ferramentas comuns de Kubernetes, sem armazenamento de sessão compartilhado.
Aqui vai a leitura honesta do operador: a sessão de protocolo nunca foi onde morava o nosso estado difícil. Num servidor de anúncios, o estado que importa são as concessões de OAuth, a conta de anúncios ativa selecionada, os limites de gasto e os orçamentos de taxa por plataforma. Esse estado fica em um banco de dados atrelado ao usuário autenticado, porque precisa sobreviver a uma conexão interrompida. O que o handshake antigo acrescentava era uma segunda sessão, frágil, que podia morrer independentemente da real, e um deploy ou a reinicialização do balanceador encerrava as sessões de protocolo enquanto as sessões de autenticação seguiam bem. Eliminar essa camada remove toda uma classe de falhas confusas. A substituição da especificação para o estado legítimo entre chamadas são handles gerados pelo servidor, passados como argumentos comuns das ferramentas, que é como os fluxos de anúncios já funcionam: selecionar uma conta, receber um handle, repassá-lo adiante. Assine-os e faça-os expirar, já que qualquer instância agora pode recebê-los a frio.
A aresta afiada é a semântica de repetição
Escondida sob a história do stateless está a mudança com mais chance de causar incidentes com dinheiro de verdade: a retomada de streams SSE e o reenvio de mensagens são removidos. Na versão 2026-07-28, um stream de resposta interrompido perde a requisição em andamento, e o cliente precisa reenviá-la como uma nova requisição com um novo ID. Para get_campaign_performance, repetir não custa nada. Para a criação de uma campanha ou a atualização de um orçamento, uma repetição às cegas é como um agente gasta em dobro. Se o seu servidor altera dinheiro, os contratos das suas ferramentas precisam de chaves de idempotência e o seu backend precisa de deduplicação, porque o transporte não promete mais reenviar o resultado original. Nossas escritas entregues têm gate com as flags dry_run e confirm_destructive, o que reduz o raio de impacto, mas um gate não é deduplicação. Trate-os como dois controles separados e construa os dois.
Tasks combinam com anúncios
Tasks sai do núcleo experimental e vira uma extensão oficial, io.modelcontextprotocol/tasks. O redesenho troca a chamada bloqueante tasks/result por polling via tasks/get, adiciona tasks/update para entrada do cliente para o servidor no meio da tarefa e deixa os servidores devolverem handles de tarefa sem solicitação, sem opt-in por requisição. O texto do The Register destaca o ponto da durabilidade: as tarefas são endereçadas por handles estáveis, então um cliente pode guardar o ID da tarefa e retomar o polling depois de uma falha ou reinicialização.
O trabalho com anúncios é de longa duração por natureza. Uma auditoria em um MCC de 200 campanhas. Uma pausa em massa em conjuntos de anúncios de uma temporada inteira, o tipo de trabalho para o qual existe a nossa documentação de operações em massa no Meta. Um relatório entre plataformas de 90 dias. Hoje tudo isso precisa terminar dentro do prazo que o proxy na frente do seu servidor impõe, e todo deploy de produção tem um proxy assim. Tasks baseado em polling combina com a infraestrutura HTTP sem graça: nenhum stream preso para cuidar, nada para um timeout de borda cortar pela metade.
tasks/update é a parte discretamente importante para anúncios em especial. Uma tarefa que aceita entrada no meio da execução é uma tarefa que pode parar antes da metade destrutiva e perguntar. Hoje um gate de aprovação são duas tarefas: um dry run e depois uma confirmação explícita. Com Tasks, o mesmo padrão de segurança pode ser uma única operação durável com uma pausa humana dentro, que é um formato melhor para agentes que planejam trabalho em várias etapas. A ressalva é estrutural: as extensões vêm desativadas por padrão e exigem opt-in explícito dos dois lados, então isso compensa quando Claude e ChatGPT lançarem suporte de cliente, não antes.
MRTR troca pedidos do servidor
As requisições iniciadas pelo servidor (roots/list, sampling/createMessage, elicitation/create) são substituídas pelo padrão Multi Round-Trip Requests. Um servidor que precisa de mais informações retorna um resultado com resultType: "input_required" carregando suas perguntas; o cliente reenvia a requisição original com as respostas anexadas em inputResponses. Todo resultado agora traz um resultType obrigatório, e os resultados de servidores de protocolos anteriores que o omitem devem ser tratados como completos, o que mantém sãs as frotas de versões mistas.
A elicitation era como um servidor perguntava “qual das suas 14 contas de anúncios você quis dizer?” no meio de uma chamada. O MRTR mantém a pergunta e inverte a mecânica. O servidor não pode mais deixar uma pergunta pendente na memória do processo, porque a repetição pode cair em outra instância; todo o contexto de que a pergunta precisa vai em requestState. É chato de adaptar e correto por design. Também formaliza uma lição que todo servidor remoto de anúncios aprende cedo: os clientes de chat somem no meio da conversa o tempo todo, então qualquer pergunta no meio de uma operação que não seja retomável é uma pergunta que vai deixar uma operação encalhada. Vimos fluxos pela metade o bastante para considerar isso a especificação alcançando a realidade.
O PaidSync é um servidor MCP remoto para trabalho com anúncios. 630+ ferramentas em 14 plataformas, um só endpoint, a partir do Claude ou do ChatGPT.
Ver o servidor MCP Comece grátisA autorização fica mais difícil de errar
Três reforços, todos com fonte no changelog. Os servidores de autorização devem incluir o parâmetro iss nas respostas de autorização conforme a RFC 9207, e os clientes devem validá-lo contra o emissor registrado antes de resgatar um código. As credenciais de cliente agora são explicitamente atreladas ao servidor de autorização que as emitiu: indexadas por emissor, nunca reutilizadas entre emissores, registradas de novo quando o emissor muda. E os clientes devem declarar um application_type durante o registro, o que corrige uma antiga classe de rejeições de redirect para localhost em agentes de CLI e desktop. O Enterprise-Managed Authorization também chega como extensão formal, dando às organizações controle centralizado sobre quais servidores MCP seus agentes podem usar.
Por que isso importa mais para servidores de anúncios do que para a maioria: um único token bearer de um servidor MCP remoto de anúncios dá acesso a contas de anúncios reais no Google, Meta e LinkedIn, com orçamentos reais por trás. É exatamente o tipo de alvo para o qual os ataques de mix-up de OAuth foram inventados, e a validação de iss é a contramedida padrão. A maior parte das novas obrigações cai no código do cliente, mas só funcionam se os servidores publicarem metadados de autorização precisos para validar. Para registro, a base do PaidSync entregue hoje é metadados de servidor de autorização da RFC 8414 e metadados de recurso protegido da RFC 9728 nos caminhos well-known, um security.txt publicado, um MCP server card e um manifesto de autenticação de agente, e revogação de sessão para que o usuário possa cortar o acesso de um cliente conectado a qualquer momento. Essa é a revisão estável atual feita com cuidado, não uma implementação da 2026-07-28; dizemos isso com clareza porque ler uma especificação não é entregá-la.
DCR sai, CIMD entra
O Dynamic Client Registration (RFC 7591) é formalmente depreciado como mecanismo de registro de clientes do MCP em favor dos Client ID Metadata Documents. Continua disponível por compatibilidade com servidores de autorização que ainda não migraram. No CIMD, o client_id é uma URL HTTPS que o operador do cliente controla, e o servidor de autorização busca os metadados do cliente nessa URL.
Esta mudança nós teríamos votado duas vezes. O DCR fazia todo agente desconhecido se autorregistrar no seu servidor de autorização: linhas anônimas, nomes autodeclarados, reputação zero e um job periódico de limpeza para registros que ninguém nunca usou. O CIMD muda a pergunta na porta de “isto se registrou?” para “quem é dono deste domínio?” Para um servidor que fica na frente de gasto com anúncios, essa diferença é de nível de política. Ela torna possíveis allowlists de plataformas de agentes conhecidas e torna honesta a tela de consentimento: o nome do cliente que o usuário aprova é respaldado por um domínio, não digitado pelo próprio cliente. O conselho de migração se escreve sozinho: mantenha o DCR funcionando durante a janela de depreciação, prefira o CIMD para todo cliente que apresentar um e comece já a redigir a política de confiança, porque a política é a parte difícil, não a análise.
MCP Apps e as mudanças de encanamento
MCP Apps
O MCP Apps chega como extensão oficial no novo framework de extensões. A documentação de extensões o descreve como a possibilidade de os servidores exibirem elementos de interface interativos, gráficos, formulários, players de vídeo, inline nas conversas. Para o trabalho com anúncios, os candidatos são óbvios: uma tendência de gasto como um gráfico de verdade em vez de uma tabela em ASCII, uma prévia de campanha antes do lançamento, um formulário de aprovação para uma alteração em massa com uma caixa de seleção por campanha. Um formulário de aprovação renderizado é uma superfície de segurança materialmente melhor do que um “sim, confirmo” em texto livre. A mesma ressalva de Tasks: opt-in dos dois lados, então a adoção pelos clientes dita o relógio.
Headers e cache
Os POSTs de Streamable HTTP agora devem trazer os headers Mcp-Method e Mcp-Name, para que os gateways possam rotear e limitar a taxa sem analisar corpos JSON. Com 438 ferramentas ativas no nosso servidor, política por ferramenta na borda, limites mais rígidos para ferramentas de mutação, regras de WAF que nunca tocam um corpo, é uma capacidade barata que vamos aproveitar. Os resultados de listas (tools/list e afins) agora devem trazer ttlMs e cacheScope, o que significa que os clientes finalmente podem parar de puxar um catálogo grande de ferramentas a cada turno. A especificação também incentiva os servidores a devolver as ferramentas em ordem determinística para melhorar os acertos no cache de prompt dos LLMs; para catálogos do nosso tamanho, isso é uma alavanca direta de custo de tokens. Escrevemos sobre a troca do tamanho do catálogo em por que a contagem de ferramentas é um recurso.
Depreciações com prazo real
Roots, Sampling e Logging são depreciados, junto com o transporte legado HTTP+SSE, sob um novo ciclo de vida de recursos que garante uma janela mínima de transição de doze meses. Nada disso pesa aqui. O sampling no servidor sempre foi a forma errada numa fronteira de cobrança, já que significa um servidor de ferramentas gastando os tokens de modelo de outra pessoa; o logging passa para stderr ou OpenTelemetry, o que os servidores de produção já fazem. A política de ciclo de vida em si é a vitória: as aposentadorias agora vêm com um cronograma em que você pode se basear, em vez de uma surpresa.
O que isto não muda
Fatos diretos, sem leitura exagerada
O PaidSync não entregou a revisão 2026-07-28. Nosso servidor de produção fala o protocolo estável atual que os clientes do Claude e do ChatGPT falam hoje, e a nossa adoção vai acompanhar a deles, porque uma especificação que só um lado fala é uma especificação que ninguém fala. Os prazos de suporte dos clientes pertencem aos fornecedores dos clientes, e não vamos chutá-los em público. As extensões, incluindo Tasks e MCP Apps, vêm desativadas por padrão e exigem opt-in das duas pontas. Nada é removido no primeiro dia: os recursos depreciados têm janela mínima de doze meses e o DCR segue funcionando por compatibilidade. E a especificação corrige o estado do protocolo, não o julgamento sobre anúncios. Gasto desperdiçado, rastreamento de conversões quebrado e más escolhas de público sobrevivem intactos a toda revisão de protocolo; essa camada é tratada em como encontrar gasto desperdiçado em anúncios com IA.
Primeira semana para criar agentes
Se você roda ou está construindo um servidor MCP remoto, esta é a ordem em que trabalharíamos, com base em rodar um em produção.
1. Audite toda ferramenta de mutação quanto à segurança de repetição. A retomada acabou; os clientes vão reenviar requisições perdidas. Adicione chaves de idempotência a qualquer ferramenta que crie ou altere algo que custa dinheiro.
2. Mova o estado entre chamadas para handles gerados pelo servidor. Tudo o que vive na memória do processo atrelado a uma sessão de protocolo morre com esta revisão. Handles como argumentos de ferramentas, assinados e com expiração.
3. Verifique seus metadados de OAuth. A nova validação de iss no cliente e a vinculação ao emissor só funcionam contra documentos well-known precisos das RFC 8414 e RFC 9728. Publique-os, mantenha-os verdadeiros.
4. Redija uma política de confiança de CIMD. Decida quais domínios de clientes você vai colocar na allowlist e como será o fallback de DCR anônimo durante a janela. Primeiro a política, depois o código.
5. Mapeie as ferramentas de longa duração para Tasks. Liste toda ferramenta que pode passar do prazo do seu gateway e marque quais precisam de entrada no meio da execução, porque essas viram pausas de aprovação com tasks/update.
6. Torne tools/list determinístico e defina TTLs honestos. Ordem estável mais ttlMs é economia de tokens de graça para todo cliente com cache de prompt.
Gerencie anúncios pelo Claude ou pelo ChatGPT com um único endpoint MCP. O plano gratuito inclui 100 tarefas por mês, no valor de $50, sem exigir cartão.
Comece grátis Ver preçosAdicionar ao ChatGPT: abra o PaidSync.ai no diretório de plugins do ChatGPT, instale e faça login.
Adicionar ao Claude: abra o PaidSync.ai no diretório de conectores do Claude, clique em Conectar e faça login.
Perguntas frequentes
O que mudou na especificação MCP de 2026-07-28?
A revisão torna o MCP stateless: o handshake initialize e o header Mcp-Session-Id são removidos, cada requisição carrega a versão do protocolo e as capacidades do cliente em _meta, e um novo RPC server/discover anuncia as capacidades do servidor. A retomada de streams SSE é removida, então streams interrompidos significam requisições reenviadas. Tasks passa do núcleo experimental para uma extensão oficial com tasks/get baseado em polling e entrada no meio da execução via tasks/update. Multi Round-Trip Requests substituem as chamadas de elicitation, sampling e roots iniciadas pelo servidor. A autorização é reforçada com a validação de iss da RFC 9207 e credenciais atreladas ao emissor. O Dynamic Client Registration é depreciado em favor dos Client ID Metadata Documents. Roots, Sampling, Logging e HTTP+SSE são depreciados com janela mínima de doze meses. Fonte: o changelog oficial, lido em 1 de agosto de 2026.
A especificação 2026-07-28 quebra os servidores MCP existentes?
Não no primeiro dia. A versão adota um ciclo de vida formal de recursos com janela mínima de depreciação de doze meses, o DCR continua funcionando por compatibilidade, e os clientes devem tratar como completos os resultados de servidores de protocolos anteriores que omitem o novo campo resultType. A mudança que merece atenção imediata é a semântica de repetição: a retomada e o reenvio de mensagens são removidos, então um cliente que perde um stream de resposta reenvia a requisição. Servidores que expõem ferramentas de mutação, como criação de campanhas ou alterações de orçamento, devem adicionar chaves de idempotência para que uma escrita reenviada não seja aplicada duas vezes.
O que substitui o Dynamic Client Registration no MCP?
Client ID Metadata Documents (CIMD). Em vez de se autorregistrar em cada servidor de autorização pela RFC 7591, o cliente usa como client_id uma URL HTTPS que ele controla, e o servidor de autorização busca os metadados do cliente nessa URL. A identidade passa a ser vinculada ao domínio e verificável, o que permite aos operadores de servidores criar políticas de allowlist para plataformas de agentes conhecidas e exibir telas de consentimento baseadas em um domínio, e não em um nome autodeclarado. O DCR é depreciado, mas continua disponível para servidores de autorização que ainda não oferecem suporte a CIMD.
O PaidSync já implementa a especificação MCP de 2026-07-28?
Não. O servidor MCP de produção do PaidSync roda sobre o protocolo estável atual que os clientes do Claude e do ChatGPT usam hoje. A base entregue é metadados de servidor de autorização da RFC 8414 e metadados de recurso protegido da RFC 9728 em endpoints well-known, um security.txt e um MCP server card publicados, revogação de sessão e escritas com gate com flags dry_run e confirm_destructive. A adoção da nova revisão vai acompanhar o suporte dos clientes no Claude e no ChatGPT.