MCP 01/10/2026

Servidores remotos conectados a um núcleo central por rotas distribuídas

MCP 2026-07-28: o que muda para servidores remotos

A revisão que muda o modelo mental

A versão estável mais recente do MCP, a revisão 2026-07-28, mudou mais do que alguns campos de uma mensagem. Ela permite que um servidor MCP remoto trabalhe de forma muito mais próxima de um serviço HTTP convencional: agora as requisições carregam os metadados necessários, podem ser roteadas por cabeçalhos e não dependem de uma mesma sessão persistente para chegar a uma instância específica.

Isso muda a vida de quem tratava todo servidor MCP remoto como um processo stateful e precisava manter conexões e IDs de sessão.

Diagrama abstrato sobre servidores MCP remotos e roteamento distribuído

O que mudou

Núcleo stateless

Nessa revisão, cada requisição pode carregar a versão do protocolo, o ID do cliente e as capacidades no campo _meta. O cliente pode chamar server/discover para descobrir as capacidades disponíveis antes de chamar uma ferramenta, mas a arquitetura não precisa mais depender de um handshake persistente para cada instância.

Na prática, isso facilita o balanceamento, a escalabilidade horizontal e o reinício de instâncias. Porém, um efeito colateral é que o estado de negócio não pode ficar implicitamente preso à conexão.

Roteamento por headers

Nessa última revisão, o método e o nome da ferramenta podem ser transportados em cabeçalhos HTTP padronizados, permitindo que os gateways observem e apliquem regras antes de o pedido chegar ao servidor MCP.

Isso cria uma separação bastante útil:

o gateway trata a autenticação, o roteamento e os limites;
o servidor trata a execução da ferramenta;
o sistema de auditoria registra quem chamou o quê e com qual versão.

Para que essa separação funcione, é necessário que os headers sejam validados e também que o servidor não aceite um nome de ferramenta divergente escondido no corpo da requisição.

Compatibilidade entre revisões

O MCP usa identificadores no formato de data. A especificação permite que clientes e servidores suportem mais de uma revisão, e o cliente deve escolher uma versão conhecida por ambos. Se um servidor não suportar a versão requisitada, ele deve informar quais versões estão disponíveis; então, o cliente decide se pode tentar uma nova requisição.

Com isso, uma estratégia de migração razoável é manter o novo código compatível com a revisão anterior durante a transição, registrar a versão negociada e testar clientes antigos em paralelo.

O que muda em um servidor simples

Se o servidor armazenava dados da conversa apenas na memória da conexão, será necessário reavaliar essa decisão. Se qualquer instância puder receber qualquer requisição, o estado necessário para executar a operação precisa estar:

na própria requisição;
em armazenamento compartilhado;
ou em um serviço externo com consistência e autorização definidas.

Não use o clientInfo no controle de acesso. Ele serve apenas para interoperabilidade, não para segurança. A autorização precisa ser feita via credenciais devidamente validadas.

Autorização não é responsabilidade da ferramenta

Ferramentas sensíveis não devem retornar “não autorizado” como se fosse uma falha normal. O mais correto é validar o token e fazer o servidor HTTP responder com 401 quando a requisição não tiver uma credencial válida. Assim, o cliente consegue identificar o fluxo de autorização.

Para cada servidor, você deve documentar:

ferramentas que são públicas;
ferramentas que exigem autorização;
qual identidade pode chamar cada ferramenta;
quais dados podem aparecer nos argumentos e resultados;
como os tokens são revogados;
como as requisições são auditadas.

Em servidores que possuem ferramentas públicas e protegidas, implementar a autorização por ferramenta pode ser útil, mas vai exigir uma análise mais criteriosa das mensagens JSON-RPC e proteção contra requisições em lote que misturem operações com diferentes tipos de permissão.

Modelo de checklist para migração

[ ] identificar a revisão MCP suportada por cada cliente e servidor;
[ ] registrar a versão efetivamente negociada;
[ ] testar server/discover e a resposta para versões incompatíveis;
[ ] remover dependências desnecessárias de sessão persistente;
[ ] mover estado compartilhado para armazenamento explícito;
[ ] validar headers e corpo antes do roteamento;
[ ] separar autenticação, autorização e execução da ferramenta;
[ ] aplicar limites de tamanho, tempo e concorrência;
[ ] adicionar testes de compatibilidade com a revisão anterior;
[ ] revisar logs para não expor tokens nem argumentos sensíveis.

Compatibilidade gradual

Para fazer uma migração mais segura, você pode começar com um endpoint que aceite a revisão nova e a anterior. O servidor registra métricas por versão e mantém uma suíte de testes de contrato para cada SDK usado pelo projeto. O endpoint legado só deve ser desativado após observar clientes reais em funcionamento.

O SDK Go oficial, por exemplo, já documenta suporte à revisão 2026-07-28 e a negociação com revisões legadas. O SDK Python também registra mudanças na forma como metadados do cliente e informações do servidor são expostos. Isso reforça uma regra simples: atualizar o protocolo e atualizar o SDK são tarefas relacionadas, mas não necessariamente simultâneas em todos os consumidores.

A versão 4.0 da biblioteca FastMCP também implementou o suporte à revisão 2026-07-28, mantendo compatibilidade com o legado.

Conclusão

A revisão 2026-07-28 torna o MCP mais adequado a uma infraestrutura remota distribuída, mas exige que os projetos sejam explícitos sobre versão, estado, autorização e observabilidade. A principal mudança não é escrever menos código: é deixar de depender de propriedades implícitas da conexão.