Guia de Sobrevivência do Candidato a Lançamento do MCP: Aplicativos, Autenticação, Depreciações e Esquemas de Ferramentas

O candidato a lançamento do MCP 2026-07-28 é a maior revisão de especificação desde o lançamento do MCP. Também é um teste de compatibilidade para todos que estão construindo clientes, servidores, SDKs, gateways e ferramentas de desenvolvedor em torno do protocolo.

O candidato a lançamento foi bloqueado em 21 de maio de 2026. A especificação final está programada para 28 de julho de 2026. Esta janela é o momento para testar implementações reais e encontrar pontos problemáticos de migração.

1. Verifique suas suposições de transporte

A maior mudança é que o MCP agora é sem estado na camada de protocolo.

Se sua implementação atual de HTTP Streamable depende de initialize, initialized ou Mcp-Session-Id, você tem trabalho de migração. No candidato a lançamento, cada solicitação carrega a versão do protocolo, informações do cliente e capacidades em _meta. O novo método server/discover cobre casos em que um cliente precisa das capacidades do servidor antecipadamente.

Uma solicitação tools/call sobre HTTP Streamable agora inclui cabeçalhos como:

MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

Isso muda a forma como a infraestrutura pode lidar com o tráfego do MCP. Um gateway não precisa mais inspecionar corpos JSON apenas para rotear ou limitar a taxa de operações comuns. Um balanceador de carga pode enviar solicitações para qualquer instância de servidor porque o protocolo não assume mais uma sessão fixa.

A questão de compatibilidade é simples: seu servidor ainda oculta o estado necessário na conexão?

Se sim, mova esse estado para um manipulador de aplicativo explícito. Por exemplo, uma ferramenta pode retornar um basket_id, browser_id ou manipulador de trabalho, e o modelo pode passá-lo de volta como um argumento normal da ferramenta mais tarde. Isso torna o estado visível para o modelo e portátil entre instâncias de servidor.

2. Teste fluxos de solicitação de servidor para cliente

O MCP sem estado ainda precisa de interação durante uma chamada. O candidato a lançamento muda como isso funciona.

Solicitações iniciadas pelo servidor só podem acontecer enquanto o servidor está processando uma solicitação do cliente. Para elicitação, raízes ou fluxos de amostragem, o servidor retorna um InputRequiredResult, e o cliente tenta novamente a chamada original com inputResponses e requestState.

Isso significa que os clientes precisam preservar e reproduzir os dados corretos. Os servidores precisam tratar a nova tentativa como uma continuação, mesmo que ela chegue a outra instância.

Um bom caso de teste é uma chamada de ferramenta destrutiva que pede confirmação. O servidor deve retornar uma solicitação de entrada, o cliente deve coletar a resposta e a nova tentativa deve ser bem-sucedida sem depender da memória da conexão.

3. Trate os aplicativos MCP como superfícies de aplicativo reais

Os Aplicativos MCP permitem que os servidores forneçam interfaces HTML interativas que os hosts renderizam em iframes isolados.

Esta é uma grande mudança na experiência do desenvolvedor, mas também tem implicações de segurança e de produto. As ferramentas podem declarar modelos de UI com antecedência, o que permite que os hosts pré-busquem, armazenem em cache e revisem antes que qualquer coisa seja executada. A UI ainda se comunica por meio do protocolo JSON-RPC do MCP, então ações impulsionadas pela UI passam pelo mesmo caminho de consentimento que chamadas de ferramentas.

Se você mantém um host, teste seu isolamento de iframe, prompts de permissão e comportamento de cache. Se você mantém um servidor, verifique se suas declarações de modelo de UI são determinísticas e não dependem de estado de sessão oculto.

O modelo de Aplicativos recompensará a disciplina consistente: modelos explícitos, limites claros de ferramentas e nenhum comportamento de rede surpresa.

4. Fortaleça a autorização agora

O candidato a lançamento aperta a autorização do MCP em torno de implementações do OAuth 2.0 e OpenID Connect.

Os clientes agora precisam validar o parâmetro iss nas respostas de autorização sob o RFC 9207. Os servidores de autorização devem começar a enviar iss agora, pois espera-se que futuros clientes rejeitem respostas sem ele.

A Registro Dinâmico de Clientes também muda. Os clientes declaram application_type do OpenID Connect, o que é importante para clientes de desktop e CLI que usam URIs de redirecionamento localhost. Os clientes também vinculam credenciais registradas ao issuer do servidor de autorização emissor.

A lista de verificação de migração aqui é direta:

• Verifique o manuseio de iss nos clientes.
• Confirme que os servidores de autorização enviam iss.
• Verifique os metadados de Registro Dinâmico de Clientes.
• Re-registre quando um recurso se mover entre servidores de autorização.

Isso é especialmente relevante para o MCP porque um cliente pode se conectar a muitos servidores. Os riscos de confusão não são teóricos nessa configuração.

5. Pare de construir novos trabalhos em recursos principais depreciados

Raízes, Amostragem e Registro estão depreciados no candidato a lançamento.

Eles ainda funcionam. A depreciação é apenas uma anotação para este lançamento, e os métodos, tipos e flags de capacidade continuam a funcionar em todas as versões de especificação publicadas dentro de um ano a partir dele. A remoção exigiria um SEP separado.

Ainda assim, novos trabalhos devem ser movidos para outro lugar:

• Raízes devem ser movidas para parâmetros de ferramentas, URIs de recursos ou configuração de servidor.
• A amostragem deve ser movida para integração direta com APIs de provedores de modelo.
• O registro deve ser movido para stderr para stdio ou OpenTelemetry para observabilidade estruturada.

Se você mantém abstrações de SDK, este é o momento de adicionar avisos sem quebrar os usuários. Se você mantém a documentação, pare de ensinar recursos depreciados como o caminho padrão.

6. Valide esquemas de ferramentas contra JSON Schema 2020-12

Os inputSchema e outputSchema das ferramentas agora usam o JSON Schema 2020-12 completo.

Para esquemas de entrada, a raiz ainda precisa ser type: "object", mas os esquemas agora podem usar oneOf, anyOf, allOf, condicionais, $ref e $defs. Os esquemas de saída são irrestritos. structuredContent pode ser qualquer valor JSON em vez de apenas um objeto.

Isso cria oportunidades e riscos.

Os servidores devem limitar a profundidade do esquema e o tempo de validação. As implementações não devem auto-desreferenciar URIs externos $ref. Clientes que fizeram suposições sobre esquemas simples apenas de objetos precisam de testes contra esquemas compostos.

Além disso, verifique o tratamento de erros. O erro de recurso ausente muda do código personalizado do MCP -32002 para o padrão JSON-RPC -32602 Parâmetros Inválidos. Se seu cliente corresponder ao código literal, atualize-o.

À medida que você trabalha na lista de verificação, se encontrar quaisquer problemas ou pontos de fricção significativos, traga-os para a comunidade. Você pode abrir uma questão no repositório de especificação. Para perguntas de implementação, o relevante

As empresas brasileiras que utilizam o MCP devem se preparar para as mudanças significativas na arquitetura de seus sistemas. A transição para um protocolo sem estado pode otimizar a escalabilidade e a eficiência das aplicações, mas requer atenção cuidadosa às novas diretrizes de migração e autenticação.