MCP 2026: escalonamento remoto fica mais fácil
Em 28 de julho de 2026, o Model Context Protocol (MCP) passará pela sua maior transformação desde o lançamento. A especificação 2026-07-28, cujo release candidate foi publicado em 21 de maio de 2026, introduz mudanças estruturais que eliminam sessões, removem o handshake de inicialização e tornam o protocolo completamente stateless na camada de transporte. Para times que operam agentes em produção, isso significa uma simplificação drástica da infraestrutura de escalonamento, alinhando o MCP aos padrões consolidados da web.
Até agora, escalar servidores MCP remotos exigia roteamento sticky ou armazenamento compartilhado de sessão, pois cada instância mantinha estado por conexão. Com a nova especificação, cada requisição carrega todas as informações necessárias para seu processamento, permitindo que balanceadores de carga comuns distribuam o tráfego sem afinidade de sessão. Essa mudança é sustentada por seis Propostas de Aprimoramento da Especificação (SEPs) que concretizam a visão delineada em “O Futuro dos Transportes MCP”, de dezembro de 2025.
O núcleo stateless: escalonamento sem handshake
A remoção do handshake initialize/initialized é a mudança mais impactante. Na versão anterior, cada cliente precisava negociar capacidades e versão antes de qualquer chamada, criando um vínculo stateful. Agora, as informações do cliente, versão do protocolo e capacidades são transmitidas no campo meta de cada requisição JSON-RPC, tornando cada chamada autodescritiva.
Essa abordagem permite que qualquer instância do servidor atenda qualquer requisição, sem necessidade de sincronização de estado. Um exemplo prático de chamada de ferramenta ilustra a simplicidade:
POST /mcp HTTP/1.1
Mcp-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"meta":{"io.modelcontextprotocol/protocolVersion":"2026-07-28",
"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}Os cabeçalhos HTTP Mcp-Method e Mcp-Name permitem que gateways roteiem chamadas sem inspecionar o corpo JSON, otimizando o desempenho em arquiteturas de microsserviços.
Rodadas múltiplas e estado explícito
Com a eliminação do estado na camada de transporte, surge a questão: como lidar com ferramentas que exigem múltiplas interações? A especificação introduz Requisições de Múltiplas Rodadas. Quando uma ferramenta precisa de entrada adicional, o servidor retorna um InputRequiredResult contendo um token opaco requestState. O cliente então reenvia a chamada incluindo esse token junto com a entrada do usuário, permitindo que qualquer instância processe a resposta sem manter conexão aberta.
É crucial entender que a remoção da sessão no nível de protocolo não obriga sua aplicação a ser stateless. Servidores que precisam manter estado entre chamadas podem adotar o padrão de handle explícito, comum em APIs HTTP: a ferramenta gera um identificador (como basketid ou browserid) e o modelo o repassa como argumento em chamadas subsequentes.
Esse padrão, na prática, revela-se mais poderoso que sessões ocultas. O modelo pode compor handles entre ferramentas, raciocinar sobre eles e transferi-los entre etapas de um fluxo de trabalho. O estado deixa de ser um segredo de infraestrutura e torna-se visível e manipulável pelo modelo, ampliando a flexibilidade dos agentes.
A topologia acima demonstra como um balanceador de carga padrão pode distribuir requisições para múltiplas instâncias de servidor MCP, cada uma capaz de processar qualquer chamada de forma independente.
O diagrama do padrão de handle explícito mostra como um identificador gerado por uma ferramenta é transportado pelo modelo entre diferentes chamadas, eliminando a necessidade de estado gerenciado pelo protocolo.
Autorização empresarial gerenciada
Além do escalonamento horizontal, a governança de acesso a servidores MCP em ambientes corporativos exigia uma solução centralizada. O fluxo OAuth tradicional forçava cada funcionário a autorizar cada servidor individualmente, dificultando auditorias e misturando acesso pessoal e corporativo.
A extensão de autorização empresarial gerenciada, estabilizada em junho de 2026, implementa o Identity Assertion JWT Authorization Grant (ID-JAG). Durante o single sign-on (SSO), o cliente troca o token de identidade do usuário por um grant ID-JAG com escopo específico para um servidor alvo, usando o mecanismo de token exchange da RFC 8693. Em seguida, o cliente apresenta esse grant ao servidor de autorização do MCP para obter um token de acesso. Todo o processo ocorre em segundo plano, sem telas interativas de consentimento.
O controle de acesso é governado pelos grupos e papéis do provedor de identidade (IdP) existente. Administradores configuram permissões em um único painel, e todos os acessos geram trilhas de auditoria centralizadas. É importante notar que essa extensão é opcional e aditiva: o padrão permanece OAuth por usuário para configurações de consumo. Os servidores anunciam suporte como uma capacidade, e os clientes negociam durante a conexão. O IdP apenas valida políticas e emite o grant, sem interceptar o tráfego MCP bruto, e cada token de acesso é estritamente restrito ao servidor de destino.
Estabilidade de versão e janelas de depreciação
Para tornar o MCP viável em roteiros de longo prazo, foi introduzido um ciclo de vida formal para especificações. As funcionalidades agora transitam pelos estados Ativo → Depreciado → Removido, com uma janela mínima de depreciação de doze meses. Além disso, mudanças propostas na Standards Track devem ser validadas contra um conjunto formal de testes de conformidade, e as especificações são versionadas por data de calendário.
Na revisão 2026-07-28, várias funcionalidades legadas foram depreciadas: Roots, Sampling e Logging. Elas serão substituídas por parâmetros de ferramentas, URIs de recursos, APIs diretas de provedores e saídas de erro padrão ou streams do OpenTelemetry.
Para permitir que as equipes validem essas mudanças antes do lançamento final, foram publicados SDKs beta em quatro linguagens:
- Python:
pip install "mcp[cli]==2.0.0b1" - TypeScript:
npm install @modelcontextprotocol/server@beta @modelcontextprotocol/client@beta - Go:
go get github.com/modelcontextprotocol/[email protected] - C#:
dotnet add package ModelContextProtocol --prerelease
As linhas v1 existentes dos SDKs receberão patches de bugs e segurança por pelo menos seis meses após o lançamento final. A compatibilidade retroativa é mantida: servidores v2 continuam aceitando requisições legadas com handshake 2025-11-25, permitindo que clientes atualizem de forma independente.
O que isso significa para times que executam agentes em produção
O MCP agora é hospedado pela Agentic AI Foundation sob a Linux Foundation, garantindo governança aberta e um processo focado de aprimoramento da especificação. A introdução de cadência previsível de releases, prazos formais de depreciação e testes de conformidade estabelece o MCP como um padrão de infraestrutura confiável, não uma biblioteca instável.
Com a especificação 2026-07-28 sendo finalizada em 28 de julho e SDKs beta disponíveis, é crucial avaliar os seguintes pontos em sua implantação:
- Identifique dependências de sessão. Se sua configuração depende de roteamento sticky ou tabelas de sessão compartilhadas, a migração para o núcleo stateless permitirá a transição para balanceamento de carga round-robin padrão, simplificando a infraestrutura.
- Avalie seu fluxo de integração. Se seus servidores atualmente exigem redirecionamentos de consentimento individual, verifique se seu IdP e cliente suportam a nova extensão de troca de tokens empresariais para habilitar autorização baseada em papéis.
- Planeje a migração de versões. Se seus sistemas estão fixados na especificação original 2025-11-25, utilize a janela de depreciação de 12 meses para mapear atualizações nas assinaturas de ferramentas e recursos.
A tabela abaixo resume as principais mudanças e seus impactos:
| Área | Antes (2025-11-25) | Depois (2026-07-28) | Benefício |
|---|---|---|---|
| Sessões | Stateful, exigindo handshake | Stateless, metadados por requisição | Escalonamento horizontal simplificado |
| Autorização | OAuth por usuário, consentimento individual | Autorização empresarial gerenciada (ID-JAG) | Governança centralizada, auditoria |
| Funcionalidades depreciadas | Roots, Sampling, Logging ativos | Depreciados, substituídos por alternativas | Protocolo mais enxuto e focado |
| Ciclo de vida | Sem política formal de depreciação | Janela de 12 meses, testes de conformidade | Previsibilidade para produção |
Essas mudanças representam um amadurecimento significativo do ecossistema MCP. Ao adotar padrões web estabelecidos, o protocolo reduz a complexidade operacional e abre caminho para implantações mais robustas e escaláveis de agentes de IA. Times que migrarem proativamente estarão melhor posicionados para aproveitar as inovações futuras sem rupturas.
Perguntas Frequentes (FAQ)
Preciso reescrever meus servidores MCP existentes para a nova especificação?
Não imediatamente. A compatibilidade retroativa é mantida: servidores v2 aceitam requisições legadas com handshake 2025-11-25. No entanto, é recomendado planejar a migração durante a janela de depreciação de 12 meses, especialmente para aproveitar os benefícios de escalonamento stateless.
Como funciona a autorização empresarial se meu IdP não suporta token exchange?
A extensão de autorização empresarial é opcional. Se seu IdP não suportar RFC 8693, você pode continuar usando o fluxo OAuth por usuário padrão. A nova extensão é negociada como uma capacidade entre cliente e servidor, então não há quebra de compatibilidade.
O que acontece com as funcionalidades depreciadas como Roots e Sampling?
Elas permanecem disponíveis, mas são marcadas como depreciadas e serão removidas em uma versão futura após o período mínimo de 12 meses. A recomendação é migrar para as alternativas propostas: parâmetros de ferramentas, URIs de recursos e APIs diretas de provedores.