Grande Reescrita do MCP é Lançada Hoje. A Parte Difícil Nunca Foi o Protocolo.

A maior revisão do Protocolo de Contexto do Modelo desde o lançamento é lançada hoje. A especificação de 2026-07-28 finaliza um núcleo de protocolo sem estado, move o trabalho de longa duração para uma extensão de Tarefas redesenhada, introduz aplicativos MCP para UIs renderizadas no servidor e fortalece a autorização com um pacote de seis SEPs. O candidato a lançamento está público desde o final de maio, espera-se que os SDKs de Nível 1 ofereçam suporte dentro da janela de validação e, se você executar servidores MCP remotos, sua infraestrutura acaba de ficar dramaticamente mais simples: sem mais sessões fixas, sem armazenamento de sessão compartilhado, balanceamento de carga em round-robin, respostas de tools/list cacheáveis.

Isso é genuinamente uma boa engenharia. Também está prestes a tornar um problema que você já tem significativamente pior.

O que o núcleo sem estado realmente muda

De acordo com a especificação antiga, um servidor MCP remoto era algo com estado. As sessões precisavam ser fixadas, os gateways precisavam de inspeção profunda de pacotes para roteamento correto, e a escalabilidade horizontal significava ginástica com o armazenamento de sessões. Essa fricção atuava como um limitador natural de taxa sobre quantas ferramentas as organizações expunham a seus agentes. Configurar um novo servidor MCP era trabalho suficiente para que as equipes pensassem duas vezes.

A especificação de 2026-07-28 remove essa fricção quase completamente. Um servidor sem estado atrás de um balanceador de carga em round-robin, roteando com um cabeçalho Mcp-Method, com clientes armazenando em cache listas de ferramentas para qualquer ttlMs que o servidor permitir — essa é uma história de implantação que qualquer equipe de plataforma pode executar em uma tarde. A estrutura de Extensões significa que capacidades como Tarefas e Aplicativos se compõem de forma limpa em vez de incharem o núcleo. A política formal de descontinuação significa que as empresas podem finalmente construir sobre o MCP sem se preocupar que o chão se mova sob elas.

Então, aqui está o efeito de segunda ordem que ninguém está precificando: catálogos de ferramentas estão prestes a explodir.

Quando os servidores são baratos para implantar, sem estado para escalar e seguros para depender, cada API interna se torna um servidor MCP. Cada fornecedor de SaaS envia um. O agente que hoje escolhe entre 15 ferramentas estará escolhendo entre 150 até o final do ano. E a seleção de ferramentas — decidir qual ferramenta chamar, com quais argumentos, em qual ordem — já era o elo mais fraco na maioria dos sistemas agentes quando o catálogo era pequeno.

O protocolo nunca foi o gargalo

Vale a pena ser preciso sobre o que o MCP resolve e o que não resolve. O MCP padroniza como um agente descobre e invoca ferramentas: o formato de transmissão, o handshake, a negociação de capacidade. Não diz nada sobre se o agente invoca a ferramenta certa.

Essa distinção se perde na empolgação em torno dos marcos do protocolo. Eu vi equipes comemorarem ao conseguir fazer sua integração MCP funcionar de ponta a ponta, para depois descobrirem silenciosamente em produção que seu agente:

• Chama uma ferramenta search_orders quando o usuário perguntou sobre faturas, porque as descrições das ferramentas se sobrepõem e o modelo fez uma correspondência de padrões em "encontrar"
• Passa uma data como MM/DD/YYYY para uma ferramenta cujo esquema diz ISO 8601, e a análise tolerante do servidor a aceita silenciosamente — até que não aceita
• Tenta novamente uma operação de gravação que na verdade foi bem-sucedida, porque interpretou um tempo limite como uma falha (a nova extensão de Tarefas ajuda aqui, mas apenas se o agente a usar corretamente)
• Encadeia três chamadas de ferramentas onde uma seria suficiente, queimando latência e tokens em um caminho que um operador humano nunca tomaria

Nenhuma dessas são falhas de protocolo. Cada uma dessas chamadas era JSON-RPC compatível com a especificação. Elas são falhas de julgamento — e o julgamento não vem da camada de transporte. Vem dos dados de treinamento.

O uso de ferramentas é um comportamento aprendido, e a maioria dos modelos o aprendeu em catálogos de brinquedo

Aqui está a parte desconfortável. As capacidades de chamada de função e uso de ferramentas nos modelos de fronteira de hoje foram amplamente treinadas e avaliadas em conjuntos de ferramentas pequenos e limpos — benchmarks como variantes BFCL com um punhado de funções bem diferenciadas, ambientes de API sintéticos, demonstrações curadas. Esses dados ensinaram os modelos a sintaxe do uso de ferramentas extremamente bem. Modelos modernos quase nunca emitem chamadas de ferramentas malformadas.

O que esses dados não ensinaram — porque mal existe em escala — é discriminação entre ferramentas quase duplicadas em grandes catálogos. Quando seu cliente MCP agrega uma dúzia de servidores e apresenta ao modelo quatro ferramentas diferentes que podem todas "obter dados do cliente", cada uma com escopos, garantias de frescor e efeitos colaterais sutilmente diferentes, você está operando fora da distribuição na qual o modelo foi treinado. A especificação sem estado torna esse cenário de agregação o padrão, não o caso extremo.

As equipes que estão se adiantando a isso estão tratando a seleção de ferramentas como um problema de dados com três fluxos de trabalho concretos:

1. Dados de correção de trajetória. Você não pode corrigir erros de seleção de ferramentas que não capturou. O conjunto de dados de maior alavancagem que a maioria das equipes não está construindo é um corpus de trajetórias de agentes corrigidas: execuções reais de produção onde o agente escolheu errado, anotadas por alguém que entende o domínio o suficiente para dizer qual foi a sequência de chamadas correta e por quê. Este é um trabalho trabalhoso — um revisor precisa reconstruir a intenção, avaliar cada passo e reescrever a trajetória — mas é a diferença entre um agente que repete seus erros e um que melhora. É também precisamente o tipo de trabalho coberto na prática de dados de raciocínio e feedback humano da SyncSoft.AI, onde a validação do uso de ferramentas e a correção de trajetórias de agentes passaram de um pedido de nicho para um dos engajamentos mais comuns no último ano. Essa mudança na demanda indica onde está a dor da indústria.

2. Dados de preferência sobre candidatos a chamadas de ferramentas. Para ajuste fino ou otimização estilo RLHF, você precisa de julgamentos pareados: dado este contexto, é melhor chamar tool_A(args_x) do que tool_B(args_y)? Esses julgamentos frequentemente requerem especialização no domínio — um rotulador que não entende seu sistema de faturamento não pode classificar chamadas de ferramentas em relação a ele. A crowdsourcing genérica falha aqui; você precisa de anotadores que possam ler um esquema de API e raciocinar sobre efeitos colaterais.

3. Conjuntos de avaliação que refletem seu catálogo real. Benchmarks públicos não dirão como seu agente se comporta em relação às suas 150 ferramentas com suas convenções de nomenclatura e capacidades sobrepostas. Você precisa de conjuntos de avaliação retidos construídos a partir de suas próprias definições de ferramentas: casos adversariais com ferramentas quase duplicadas, solicitações de usuário subespecificadas e fluxos de trabalho de múltiplas etapas com um caminho conhecido como ótimo. Avaliar isso consistentemente em escala é uma disciplina própria — design de rubricas, concordância entre anotadores, rastreamento de regressão entre versões de modelos — que é o motivo pelo qual avaliação de modelos e QA se tornou uma função permanente em equipes de agentes maduras, em vez de um exercício pontual antes do lançamento.

Conclusões práticas para a janela de migração

Se você está planejando sua mudança para a especificação de 2026-07-28, aqui está o que eu adicionaria à lista de verificação padrão de migração:

Registre decisões de seleção de ferramentas, não apenas chamadas de ferramentas. A maioria da telemetria captura o que o agente chamou. Capture o que ele poderia ter chamado — o conjunto completo de candidatos apresentados em cada etapa. Sem isso, você não pode distinguir "escolheu errado entre boas opções" de "nunca viu a ferramenta certa", e essas têm correções completamente diferentes. O novo Amazon CloudWatch Coding Agent Insights aponta nessa direção para ferramentas de codificação; você quer o equivalente para cada superfície de agente que você executa.

Audite suas descrições de ferramentas como prompts, porque elas são. Com cacheável