引言
模型上下文协议（Model Context Protocol）迎来了自发布以来最大规模的一次架构修订。
MCP最初被引入时，是作为一种让AI应用将模型与工具、API、数据源、文件及外部系统连接起来的通用方式。在不到两年的时间里，它已从一个由Anthropic主导的集成项目，发展成为一个更广泛的开源协议，拥有自己的治理流程、SDK生态系统、工作组、扩展以及横跨众多AI产品的实现。
2026-07-28修订版聚焦于MCP离开开发者笔记本电脑、进入大型生产环境时出现的问题。
最主要的变更可以概括为：
MCP正在协议层转变为无状态。
这一变更从新的线上格式中移除了协议级的会话和初始化握手，使远程MCP服务器能够更轻松地部署在普通负载均衡器、无服务器基础设施、边缘计算节点和水平扩展架构之后。
但无状态传输只是本次更新的一部分。
该修订版还正式确立了一个扩展框架，重塑了长时间运行的任务，引入了多轮往返请求，增加了可路由的HTTP头和缓存提示，强化了授权机制，扩展了JSON Schema支持，并制定了一项正式的功能弃用策略。
在协议本身之外，MCP生态系统还在增加交互式应用、企业级托管授权、私有网络隧道以及更强大的开发者工具。
正是在这一点上，MCP开始不再像一个便捷的智能体连接器，而更像生产级基础设施。
MCP采用速度迅猛增长
源报告强调了MCP使用量的增长速度。
根据源文章引用的Claude开发者发布公告：
- MCP SDK月下载量已超过4亿次。
- 年度内SDK月使用量大约增长了四倍。
- TypeScript和Python SDK的累计下载量均跨越了非常大的里程碑。
- 已有数百个MCP集成通过Claude的连接器生态可用。
这些7月底的具体数据属于发布公告中的指标，而非核心规范中发布的数字。
Anthropic早前的一份官方公告提供了一个有用的参照点：2026年1月，Anthropic表示MCP已达到每月1亿次下载。
这意味着在7月协议重新设计之前，生态系统已经相当庞大。
因此，本次更新的意义不在于MCP试图在未来某天变得有用，而在于维护者正在围绕已在生产规模上显现的问题重新设计协议。
这些问题包括：
- 粘性会话。
- 共享会话存储。
- 水平扩展。
- 无服务器部署。
- 网关路由。
- 认证复杂性。
- 长时间运行的智能体操作。
- 交互式界面。
- 向后兼容性。
- 协议演进。
为什么之前的有状态设计成为扩展难题
早期的远程MCP部署可以维持协议级别的会话状态。
客户端通常会初始化一个
建立连接并获得了一个会话标识符。后续请求随后需要保持与该会话的关联。
一个简化的 2025-11-25 流程如下所示：
POST /mcp HTTP/1.1
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"capabilities": {},
"clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
初始化之后，后续的调用可以携带：
Mcp-Session-Id: 1868a90c-3a3f-4f5b
这种方法对许多应用来说是可行的，但它带来了一些基础设施层面的要求。
生产环境部署可能需要：
- 粘性负载均衡器路由。
- 共享会话存储。
- 会话复制。
- 会话过期逻辑。
- 故障转移处理。
- 感知连接的可观测性。
- 对服务器重启的特殊处理。
MCP 维护者得出的结论是，这些要求与协议本身的耦合过于紧密。
新修订版本移除了这一假设。
MCP 现已在协议层面实现无状态
在 2026-07-28 协议设计中，每个请求都携带服务器解析请求所需的信息。
官方示例如下：
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "search",
"arguments": {
"q": "otters"
},
"_meta": {
"io.modelcontextprotocol/clientInfo": {
"name": "my-app",
"version": "1.0"
}
}
}
}
不再有协议级的 Mcp-Session-Id。
不再有强制性的连接会话将请求绑定到单个服务器实例。
任何兼容的服务器实例都可以处理该请求。
这对于云部署来说是一个重大的改进。
远程 MCP 服务器现在可以适配传统的架构：
客户端
↓
API 网关 / 负载均衡器
↓
MCP 服务器实例 A
MCP 服务器实例 B
MCP 服务器实例 C
请求不再因为之前某个请求落在某个实例上，就必须回到该实例。
新线上格式中移除了 initialize 握手
无状态重新设计还从 2026-07-28 线上格式中移除了旧的 initialize / initialized 生命周期。
之前初始化期间只传输一次的信息，现在通过元数据随请求一同传输。
当客户端希望提前发现服务器能力时，可以使用新方法 server/discover。
这并不意味着旧客户端会立即停止工作。
当前的 SDK 文档包含对早期协议版本的兼容性行为说明。例如，C# SDK 可以支持新的无状态
在继续与使用 2025-11-25 协议的客户端协商旧版基于会话的行为的同时，路径向前推进。
重要的迁移区别在于：
2026-07-28:
Modelo de requisição sem estado, sem sessão de protocolo.
Versões antigas:
Handshake de inicialização e comportamento sensível a sessão podem ainda ser suportados
através de negociação de versão e caminhos de compatibilidade do SDK.
Os desenvolvedores devem testar ambas as extremidades da integração, em vez de apenas atualizar o servidor e presumir que todos os clientes entenderão a nova versão.
## Protocolo sem estado não significa aplicação sem estado
Um dos erros mais fáceis de cometer é interpretar esta mudança como:
> Aplicações MCP não podem mais manter estado.
Não é isso que a especificação significa.
A **camada de protocolo** é sem estado.
A aplicação ainda pode manter estado onde for útil.
Suponha que uma ferramenta de compras crie um carrinho de compras.
O servidor pode retornar:
```JSON
{
"basket_id": "basket_8472"
}
O modelo pode passar esse valor em chamadas posteriores:
{
"basket_id": "basket_8472",
"item_id": "item_123"
}
Isso torna o estado da aplicação visível como dados normais de ferramenta, em vez de ocultá-lo em metadados de transporte.
O mesmo padrão pode ser usado para sessões de navegador, tarefas de relatórios, carrinhos de compras, IDs de fluxo de trabalho, IDs de implantação, estado de edição de documentos e tarefas analíticas de longa duração.
Por que identificadores explícitos podem ser melhores
Identificadores visíveis têm várias vantagens.
O modelo pode:
- Passá-los entre ferramentas relacionadas.
- Raciocinar sobre qual identificador pertence a qual tarefa.
- Incluí-los em logs.
- Retomá-los após novas tentativas.
- Entregá-los a outra etapa do fluxo de trabalho.
O servidor pode:
- Validar o identificador.
- Expirá-lo.
- Vinculá-lo a um usuário ou locatário.
- Rejeitar estados expirados.
- Armazenar o estado real em um banco de dados.
Portanto, MCP sem estado transfere o gerenciamento de estado da camada de transporte para o design explícito da aplicação.
Serverless e escalabilidade horizontal ficam muito mais fáceis
O artigo de origem destacou implantações serverless, um dos resultados mais práticos do novo protocolo.
Quando as requisições são autocontidas, os servidores MCP podem operar mais facilmente em ambientes como:
- AWS Lambda.
- Cloudflare Workers.
- Vercel.
- Outras funções serverless.
- Plataformas de autoescalonamento de contêineres.
- Implantações Kubernetes sem estado comuns.
- Ambientes de borda.
Isso não significa que toda carga de trabalho MCP rodará automaticamente em qualquer plataforma serverless.
Os desenvolvedores ainda precisam considerar tempo de execução, suporte a streaming, inicialização a frio, estado persistente da aplicação, chaves, rede de saída, tarefas de longa duração, requisitos de sistema de arquivos e conexões com banco de dados.
O protocolo não exige mais uma arquitetura de sessão, o que elimina uma grande barreira.
Balanceamento de carga round-robin torna-se o padrão natural
Servidores com escalabilidade horizontal não precisam mais vincular um único cliente a uma única instância na camada de protocolo.
Isso significa que balanceadores de carga round-robin simples podem distribuir requisições entre várias instâncias.
Isso melhora:
- Autoescalonamento.
- Substituição de instâncias.
- Recuperação de falhas.
- Implantações contínuas.
- Roteamento multirregional.
- Simplicidade da infraestrutura.
Isso também muda a forma como autores de servidores pensam sobre estado oculto em memória.
Se uma ferramenta funciona apenas porque uma requisição anterior preencheu um dicionário em algum processo, essa implementação pode falhar quando a próxima requisição chegar a outra instância.
Um bom teste de migração é:
Se cada chamada de ferramenta cair em um processo de servidor diferente, o mesmo fluxo de trabalho ainda funciona?
Se a resposta for não, o servidor contém uma dependência de estado da aplicação que precisa se tornar explícita ou migrar para armazenamento compartilhado persistente.
Requisições de múltiplas idas e voltas substituem conexões persistentes
O design sem estado ainda precisa de uma forma para o servidor solicitar mais informações ao cliente.
Exemplos incluem confirmação do usuário, parâmetros adicionais, perguntas guiadas, respostas geradas pelo modelo ou valores relacionados ao espaço de trabalho.
O novo mecanismo são as Requisições de Múltiplas Idas e Voltas (Multi Round-Trip Requests, ou MRTR).
Uma ferramenta pode retornar um resultado incompleto:
{
"resultType": "input_required",
"inputRequests": {
"confirm": {
"type": "elicitation",
"message": "Excluir 3 arquivos?",
"schema": {
"type": "boolean"
}
}
},
"requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}
O cliente coleta as respostas necessárias.
Em seguida, ele repete a chamada original usando inputResponses e o requestState retornado.
Como o estado é transportado no fluxo da requisição, outra instância do servidor pode processar a próxima rodada.
Isso é muito mais alinhado com arquiteturas sem estado do que exigir conexões persistentes de longa duração entre servidor e cliente.
Roteamento baseado em cabeçalhos torna o MCP mais amigável para gateways
O novo formato Streamable HTTP adiciona metadados de operação diretamente nos cabeçalhos HTTP.
Cabeçalhos importantes incluem:
Mcp-Method: tools/call
Mcp-Name: search
Isso é importante para infraestrutura de produção.
Gateways de API, firewalls de aplicação web, limitadores de taxa ou camadas de observabilidade podem identificar a operação sem analisar o corpo JSON.
Usos possíveis incluem:
- Rotear todas as ferramentas de busca para o mesmo pool.
- Aplicar limites mais rígidos a operações destrutivas.
- Registrar latência por nome de ferramenta.
- Medir uso por método.
- Bloquear ferramentas não permitidas no gateway.
- Criar políticas de confiabilidade independentes.
A especificação do protocolo também exige consistência entre os cabeçalhos e o corpo JSON-RPC.
O servidor deve rejeitar requisições em que ambos não sejam consistentes.
Resultados de listagem e leitura suportam cache
Clientes MCP frequentemente solicitam metadados relativamente estáveis, como listas de ferramentas, recursos, listas de prompts e leituras de recursos.
Buscar repetidamente as mesmas informações desperdiça tráfego de rede e capacidade do servidor.
A nova revisão introduz metadados de cache, como:
ttlMs
cacheScope
Esses valores permitem que o servidor indique por quanto tempo o resultado deve permanecer fresco e se o resultado pode ser compartilhado entre usuários ou contextos.
Isso é semelhante ao princípio do cache HTTP comum.
Para agentes com muitas ferramentas, isso pode reduzir carregamentos repetidos de metadados.
Rastreamento distribuído padronizado
A revisão também documenta a propagação do W3C Trace Context.
Chaves como:
traceparenttracestatebaggage
podem ser propagadas através de metadados MCP.
Isso permite que um único rastreamento distribuído acompanhe o trabalho através dos seguintes elos:
Aplicação host
→ Cliente MCP
→ Gateway MCP
→ Servidor MCP
→ APIs downstream
→ Banco de dados
Para implantações empresariais, isso é importante porque chamadas lentas de ferramentas ficam muito mais fáceis de depurar quando as equipes conseguem ver onde a latência realmente ocorre.
Extensões tornam-se recursos de primeira classe no protocolo
O protocolo também está mudando a forma como funcionalidades opcionais evoluem.
A estrutura atual dá às extensões:
- Identificadores DNS reversos.
- Negociação de capacidades.
- Versionamento independente.
- Repositórios de código dedicados.
- Mantenedores delegados.
- Um caminho formal de extensão no processo SEP.
Isso é importante porque o protocolo principal não precisa absorver toda nova ideia.
Um recurso pode primeiro amadurecer como extensão, e capacidades comprovadas podem depois se aproximar do núcleo.
MCP Apps: UI interativa dentro da conversa
Uma das extensões MCP mais visíveis são os MCP Apps.
Tradicionalmente, ferramentas MCP retornam texto, JSON estruturado ou recursos.
Algumas tarefas exigem interfaces.
Exemplos incluem dashboards, gráficos, mapas, formulários, quadros de tarefas, painéis de configuração, telas de design e players de vídeo.
MCP Apps permite que o servidor declare um recurso de UI, que o host renderiza em um iframe de sandbox.
O fluxo simplificado é o seguinte:
- Uma ferramenta declara um recurso de UI.
- O modelo chama essa ferramenta.
- O host carrega a UI em um ambiente sandbox.
- Os dados da ferramenta são passados para a interface.
- O usuário interage com o aplicativo.
- O aplicativo pode solicitar chamadas de ferramenta adicionais por meio do host.
- O host mantém controle de permissão e auditoria sobre essas operações.
O MCP Apps já é suportado por vários hosts compatíveis, incluindo o Claude e outros produtos de desenvolvimento que oferecem suporte a MCP.
Instalação básica do MCP Apps
O pacote de extensão oficial pode ser instalado com o seguinte comando:
npm install -S @modelcontextprotocol/ext-apps
O repositório oficial de exemplos pode ser executado localmente:
git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start
Esses comandos vêm da documentação oficial do MCP Apps e podem mudar conforme a extensão evolui.
Tasks: trabalhos de longa duração que não bloqueiam a conexão
As ferramentas de agentes estão cada vez mais iniciando trabalhos que não podem ser concluídos durante uma única requisição HTTP comum.
Exemplos incluem pipelines de CI, tarefas de processamento de grandes volumes de dados, implantações em nuvem, tarefas de pesquisa de longa duração, renderização de vídeo e fluxos de aprovação humana.
A extensão MCP Tasks permite que o servidor retorne um identificador de tarefa persistente, em vez de bloquear aguardando a conclusão da operação.
Os métodos definidos pela extensão oficial incluem:
tasks/get
tasks/update
tasks/cancel
As tarefas podem transitar entre os seguintes estados:
working
input_required
completed
cancelled
failed
O cliente pode fazer polling de tasks/get.
Se o servidor precisar de entrada do usuário, a tarefa pode entrar no estado input_required.
O cliente pode enviar a entrada por meio de tasks/update.
Esse design funciona mesmo em cenários de desconexão e não requer uma conexão de longa duração.
Nota importante sobre compatibilidade
A funcionalidade de tarefas existia como um recurso experimental na especificação principal de 2025-11-25.
A nova extensão Tasks não é uma simples cópia renomeada da API antiga.
A documentação oficial do SDK alerta que a extensão Tasks mais recente não é compatível no protocolo de linha com as implementações experimentais anteriores.
Aplicativos que usam a funcionalidade antiga de Tasks devem migrar, sem esperar compatibilidade automática.
Autorização gerenciada empresarial
As implantações empresariais enfrentam questões de autorização diferentes das integrações de consumo.
Uma empresa pode ter milhares de funcionários e dezenas de servidores MCP aprovados.
Ela não quer que cada funcionário autorize cada conector de forma independente.
A extensão Autorização Gerenciada Empresarial permite que as organizações gerenciem o controle de acesso de forma centralizada por meio de um provedor de identidade.
Os modos suportados de IdP empresarial podem envolver produtos como Microsoft Entra ID, Okta e sistemas de SSO empresarial.
As organizações podem decidir quais funcionários podem acessar quais servidores MCP e quando o acesso deve ser revogado.
Os funcionários autenticam-se com sua identidade corporativa, sem precisar concluir aprovações OAuth separadas para cada servidor MCP.
A documentação oficial do MCP descreve a Autorização Gerenciada Empresarial como uma extensão, e não um recurso habilitado por padrão em todos os clientes.
Tanto o cliente quanto a infraestrutura de identidade da organização precisam oferecer suporte à extensão.
O mecanismo de autorização está sendo reforçado de forma mais ampla
O trabalho principal de autorização também recebeu várias melhorias de segurança.
Verificação do emissor RFC 9207
As respostas de autorização podem incluir o parâmetro de emissor iss.
O cliente verifica o emissor antes de trocar o código de autorização.
Crie um site de apresentacao e gere leads em minutos
Descreva sua ideia uma vez e o We0 AI pode gerar um site de apresentacao, paginas e CMS, alem de ajudar a atrair clientes e trafego apos o lancamento.
Uma geração completa de projetos para registro gratuito
Melhor para experimentar um fluxo de geração completo e ver rapidamente um primeiro rascunho do projeto.
Isso ajuda a prevenir ataques de confusão de servidor de autorização.
Credenciais de cliente vinculadas ao seu emissor
As credenciais de cliente registradas não devem ser reutilizadas entre servidores de autorização não relacionados.
Quando os recursos são transferidos para outros emissores, o cliente deve ser registrado adequadamente com esse emissor.
Registro aprimorado para desktop e CLI
Esta revisão esclarece o comportamento de application_type durante o registro dinâmico de clientes.
Isso ajuda a evitar que servidores de autorização tratem aplicativos CLI nativos ou de desktop como clientes web e rejeitem URIs de redirecionamento locais.
CIMD e as novas diretrizes de registro de clientes
O projeto de autorização MCP tem avançado em direção aos Documentos de Metadados de ID do Cliente (Client ID Metadata Documents, ou CIMD) para novas implementações, preservando a compatibilidade com DCR onde necessário.
A recomendação prática é seguir a documentação de autorização atual, em vez de implementar o registro de clientes com base em tutoriais mais antigos do MCP.
JSON Schema 2020-12 completo para ferramentas
Os esquemas de ferramentas também se tornaram mais expressivos.
inputSchema e outputSchema agora oferecem suporte a todos os recursos do JSON Schema 2020-12.
Os esquemas de entrada podem usar:
oneOf
anyOf
allOf
$ref
$defs
instruções condicionais
Os esquemas de saída não estão mais limitados a uma forma estreita de objeto único.
structuredContent pode representar qualquer valor JSON suportado pelo esquema.
Isso permite que as ferramentas MCP descrevam com mais precisão APIs que possuem tipos união, campos condicionais, definições reutilizáveis aninhadas, múltiplas formas de saída, resultados em array ou escalares.
Roots, Sampling e Logging foram descontinuados
Três capacidades principais mais antigas foram oficialmente descontinuadas:
| Recurso | Direção recomendada |
|---|---|
| Roots | Parâmetros de ferramenta, URIs de recursos ou configuração do servidor |
| Sampling | Integração direta com provedores de LLM |
| Logging | stderr para stdio; OpenTelemetry para observabilidade estruturada |
A descontinuação não significa remoção imediata.
A nova política de ciclo de vida estabelece que recursos descontinuados terão um período de transição de pelo menos doze meses antes de poderem ser removidos.
Os SDKs atuais podem continuar a oferecer suporte a esses recursos para manter a compatibilidade.
A política formal de descontinuação altera o risco de atualização do MCP
O redesign sem estado inclui mudanças que quebram a compatibilidade.
Os mantenedores afirmam que não desejam que esse nível de interrupção se torne a norma.
O novo ciclo de vida de recursos define as seguintes fases:
Ativo (Active)
Descontinuado (Deprecated)
Removido (Removed)
Recursos descontinuados recebem um período mínimo de suporte antes da remoção.
Extensões também podem evoluir de forma independente do núcleo.
Isso proporciona às equipes uma migração mais previsível.
O túnel MCP resolve um problema empresarial diferente
A revisão do protocolo torna mais fácil escalar servidores MCP remotos públicos.
As empresas geralmente enfrentam o problema oposto: elas não querem expor servidores publicamente.
O recurso MCP túnel da Anthropic aborda esse caso de uso para agentes hospedados pelo Claude e fluxos de trabalho suportados pela plataforma Claude.
Um gateway leve é executado dentro da rede corporativa e estabelece conexões de saída.
A Anthropic descreve esse padrão como:
- Sem endpoints MCP públicos.
- Sem regras de firewall de entrada.
- Sem IP público necessário.
- Tráfego criptografado de ponta a ponta.
Bancos de dados internos, sistemas ERP, APIs privadas, bases de conhecimento e sistemas de tickets podem permanecer dentro do perímetro da rede corporativa.
O túnel MCP continua sendo um recurso de produto do Claude, não um requisito do protocolo MCP principal.
A Anthropic atualmente o descreve como pré-visualização de pesquisa.
Aplicativos MCP e túnel não devem ser confundidos
Ambos os recursos melhoram o MCP em ambientes de produção, mas resolvem problemas diferentes.
| Recurso | Problema resolvido |
|---|---|
| Aplicativos MCP | Interfaces ricas dentro do host MCP |
| Tarefas | Operações de ferramentas persistentes e de longa duração |
| Autorização de hospedagem empresarial | Política de acesso corporativo |
centralizada |
| Túnel MCP | Acesso a servidores MCP privados sem exposição pública |
| Núcleo MCP sem estado | Transporte de protocolo escalável |
| MRTR | Entrada do cliente durante chamadas sem sessões de protocolo de longa duração |
Os servidores podem usar um, vários ou todos esses recursos.
O que os desenvolvedores de servidores MCP existentes precisam mudar?
Se o servidor já funciona com clientes MCP mais antigos, os desenvolvedores não precisam reescrever tudo imediatamente.
Eles devem executar uma migração estruturada.
Etapa 1: Inventariar dependências ocultas de sessão
Procure por código que dependa de:
Mcp-Session-Id- Dicionários por sessão em memória
- Roteamento aderente (sticky routing)
- Estado do cliente local à conexão
- Armazenamento de capacidades apenas na inicialização
- Afinidade de instância do servidor
Determine se cada dependência é estado de protocolo, estado de aplicação, estado de autenticação ou estado temporário de execução.
Mova o estado da aplicação para identificadores (handles) explícitos ou para armazenamento persistente adequado.
Etapa 2: Testar o processamento de requisições sem estado
Use versões do SDK com suporte à revisão 2026-07-28.
Em seguida, teste com múltiplas instâncias de servidor.
Uma configuração de teste útil é:
Cliente
↓
Balanceador de carga round-robin
↓
Servidor A / Servidor B / Servidor C
Envie um fluxo de trabalho em várias etapas e confirme que requisições consecutivas podem chegar a instâncias diferentes sem interromper a tarefa.
Etapa 3: Adicionar identificadores de estado explícitos
Para fluxos de trabalho que exigem estado, retorne um identificador estável:
{
"job_id": "job_7f18c9"
}
Exija que chamadas subsequentes incluam esse identificador:
{
"job_id": "job_7f18c9",
"action": "continue"
}
Valide cada identificador no lado do servidor.
Um bom identificador deve ter alta entropia, vinculação ao locatário, verificação de autorização, expiração, mecanismo de revogação e tratamento claro de erros.
Etapa 4: Atualizar regras do gateway
Se você usa Streamable HTTP, aproveite os seguintes cabeçalhos:
Mcp-Method
Mcp-Name
Adicione roteamento, limites de taxa, métricas, políticas de WAF e logs de acesso.
Etapa 5: Adicionar suporte a cache
Para respostas apropriadas de listagem e leitura, siga ou gere:
ttlMs
cacheScope
Não compartilhe conteúdo sensível em cache específico de dados de usuário entre usuários.
Etapa 6: Migrar tarefas antigas
Se o aplicativo usou a API experimental 2025-11-25 de Tasks, atualize-a para o ciclo de vida estendido.
Teste:
tasks/get
tasks/update
tasks/cancel
e o estado input_required.
Etapa 7: Revisar recursos descontinuados
Procure por Roots, Sampling e MCP Logging.
Planeje a migração para parâmetros de ferramenta explícitos ou URIs de recursos, chamadas diretas ao provedor de modelo e stderr ou OpenTelemetry.
Etapa 8: Testar novamente a autorização
Verifique validação do emissor, URIs de redirecionamento, registro do cliente, tokens de atualização, tratamento de escopos e compatibilidade com o provedor de identidade.
Implantações corporativas devem avaliar se a EMA se aplica.
Etapa 9: Testar clientes antigos
A compatibilidade retroativa é um problema de ecossistema, não apenas do servidor.
Mantenha uma matriz de testes:
| Cliente | Revisão do protocolo | Resultado |
|---|---|---|
| Cliente atual | 2026-07-28 | Caminho sem estado esperado |
| Cliente antigo | 2025-11-25 | Caminho de compatibilidade |
| Cliente não suportado | Versão antiga/desconhecida | Falha de negociação explícita |
Não presuma silenciosamente que todo
cliente será atualizado ao mesmo tempo.
Etapa 10: Adicionar observabilidade antes da produção
No mínimo, meça:
- Número de requisições.
- Nome da ferramenta.
- Latência.
- Taxa de erros.
- Duração das tarefas.
- Frequência de necessidade de entrada.
- Taxa de acerto de cache.
- Número de falhas de autenticação.
- Latência de API downstream.
- IDs de rastreamento.
Sistemas sem estado são mais fáceis de escalar, mas sistemas distribuídos ainda exigem boa observabilidade.
Exemplo: Antes e depois da migração
Antes da migração
O servidor armazena objetos de relatório em memória:
sessions[session_id]["report"] = report
A próxima chamada de ferramenta espera chegar ao mesmo processo.
Depois da migração
O servidor armazena o estado persistente:
report_id = save_report(report)
return {"report_id": report_id}
A próxima ferramenta recebe:
{
"report_id": "report_123"
}
Qualquer instância do servidor pode carregar o relatório.
A mudança importante está no nível arquitetural:
Estado de sessão oculto no transporte
→ Estado de aplicação explícito
O MCP sem estado significa custo menor?
Possivelmente, mas não automaticamente.
Implantações sem estado podem reduzir a complexidade da infraestrutura:
- Sem armazenamento compartilhado de sessão MCP.
- Menos necessidade de roteamento aderente.
- Escalonamento automático mais fácil.
- Implantação serverless mais fácil.
- Failover simplificado.
O cache também pode reduzir chamadas de metadados repetidas.
No entanto, o estado da aplicação ainda tem custo.
Se os fluxos de trabalho exigirem estado persistente, os desenvolvedores ainda podem precisar de Redis, bancos de dados SQL, armazenamento de objetos, filas de tarefas ou mecanismos de fluxo de trabalho.
O novo design permite que os desenvolvedores escolham a arquitetura de armazenamento, em vez de a sessão do protocolo impor uma específica.
O MCP está se tornando o "HTTP da era da IA"?
O artigo de origem utilizou essa analogia.
A analogia é útil, mas não deve ser interpretada literalmente.
O HTTP é o padrão fundamental de transporte da Web, usado em praticamente todos os sistemas de internet.
O MCP é um protocolo especializado, usado para conectar clientes e agentes de IA a ferramentas, recursos, prompts, interfaces e serviços externos.
O que essa analogia captura é a direção do desenvolvimento:
- Uma interface padrão.
- Muitos servidores independentes.
- Muitos clientes compatíveis.
- Convenções compartilhadas.
- Infraestrutura capaz de rotear e observar solicitações de forma genérica.
O redesenho de 2026-07-28 reforça essa analogia, pois o tráfego do MCP agora se adapta mais naturalmente à infraestrutura HTTP sem estado tradicional.
Se o MCP alcançará uma adoção semelhante à do HTTP ainda é uma questão em aberto.
O ecossistema é mais amplo que o Claude
O MCP se originou na Anthropic, mas agora é governado como um projeto de protocolo de código aberto mais amplo.
O ecossistema inclui mantenedores independentes, grupos de trabalho, propostas de aprimoramento da especificação, SDKs em várias linguagens, aplicativos MCP, tarefas, extensões de autorização empresarial, registros e implementações em diversos produtos de IA.
Por exemplo, os aplicativos MCP são desenvolvidos em conjunto com contribuidores da comunidade MCP, bem como com participantes da Anthropic, OpenAI e MCP-UI.
Isso é importante porque o valor de um protocolo aumenta quando tanto clientes quanto servidores podem implementá-lo sem depender de um único fornecedor.
Cenário atual dos SDKs
O projeto oficial do MCP mantém ou reconhece implementações de SDK em várias linguagens.
Os repositórios principais incluem SDKs para TypeScript, Python, Go, C# e outros ecossistemas.
Em junho de 2026,
o anúncio do release candidate destacou especificamente o suporte beta para quatro SDKs de primeiro nível:
- TypeScript.
- Python.
- Go.
- C#.
No final de julho, a documentação atual dos SDKs já incluía o comportamento de 2026-07-28.
Como a adoção dos SDKs ocorre de forma independente, consulte sempre as notas de versão da linguagem e versão exatas que você está utilizando.
Estratégia de migração mais segura
Para sistemas de produção, evite migrações do tipo "dia da virada".
O processo mais seguro é:
- Atualizar o ambiente de desenvolvimento.
- Executar testes de conformidade.
- Testar o cliente
2026-07-28. - Testar clientes legados.
- Habilitar a implantação sem estado no ambiente de pré-produção.
- Adicionar várias instâncias de servidor.
- Forçar a distribuição de solicitações entre instâncias.
- Testar a autenticação.
- Testar tarefas de longa duração.
- Testar os identificadores de estado da aplicação.
- Monitorar latência e erros.
- Lançar gradualmente.
Isso é especialmente importante porque a nova revisão alterou intencionalmente o comportamento central do ciclo de vida.
O que não se deve presumir
Não presuma que todo servidor será automaticamente sem servidor
O protocolo suporta de forma mais natural implantações sem servidor.
Sua aplicação pode ainda precisar de banco de dados, executores de tarefas persistentes, armazenamento de arquivos ou tempos de execução mais longos.
Não presuma que todo o estado desaparecerá
Apenas o estado de sessão em nível de protocolo é removido do novo modelo online.
O estado da aplicação continua sendo uma questão da própria aplicação.
Não presuma que os aplicativos MCP funcionarão em todos os clientes
As extensões são negociadas e o suporte dos hosts varia.
Não presuma que as tarefas são retrocompatíveis
A extensão atual de Tarefas difere das implementações experimentais anteriores.
Não presuma que a descontinuação significa inatividade
Roots, Sampling e Logging permanecem disponíveis durante o período de descontinuação.
Não presuma que todos os clientes já suportam 2026-07-28
O ritmo de adoção de SDKs e produtos varia.
Não presuma que "protocolo aberto" significa "sem necessidade de segurança"
O MCP pode executar ferramentas poderosas.
Autorização, consentimento do usuário, sandboxing, design de ferramentas, gerenciamento de segredos e auditoria continuam sendo essenciais.
Perguntas frequentes
O que é o MCP 2026-07-28?
O MCP 2026-07-28 é a maior revisão arquitetural do Model Context Protocol desde seu lançamento. Suas principais mudanças incluem um núcleo de protocolo sem estado, a remoção do handshake de sessão no novo formato online, extensões de primeiro nível, aplicativos MCP, Tarefas redesenhadas, MRTR, autorização mais forte, metadados de cache e uma política formal de descontinuação.
O MCP agora é totalmente sem estado?
A camada de protocolo do 2026-07-28 é projetada para ser sem estado. As aplicações ainda podem manter estado por meio de identificadores explícitos, bancos de dados, sistemas de fluxo de trabalho ou outros armazenamentos persistentes.
O que mudou com o Mcp-Session-Id?
O formato online do 2026-07-28 removeu o mecanismo Mcp-Session-Id em nível de protocolo. Os SDKs atuais podem ainda suportar comportamento baseado em sessão para retrocompatibilidade ao negociar revisões de protocolo mais antigas.
Posso implantar um servidor MCP no AWS Lambda ou no Cloudflare Workers?
O protocolo sem estado torna as implantações sem servidor e de borda mais fáceis, pois as solicitações não exigem mais afinidade de sessão em nível de protocolo. Seu servidor ainda precisará atender aos limites de execução, rede, armazenamento e duração do ambiente de execução.
O que é um aplicativo MCP?
Um aplicativo MCP é uma extensão oficial
que permite que ferramentas retornem interfaces interativas, como painéis, formulários, gráficos e outras experiências HTML, em hosts MCP compatíveis. A interface é executada em um iframe com sandbox e se comunica por meio do host MCP.
O que são tarefas MCP?
O recurso de tarefas permite que servidores retornem identificadores de tarefas assíncronas persistentes para trabalhos de longa duração. Clientes podem consultar o status com tasks/get, fornecer entradas necessárias com tasks/update ou cancelar operações com tasks/cancel.
O que é autorização empresarial gerenciada?
A autorização empresarial gerenciada é uma extensão do MCP que permite controle de acesso centralizado por meio do provedor de identidade da organização. Ela permite que administradores de TI gerenciem o acesso a servidores MCP com base em políticas de identidade corporativas, sem que cada usuário precise autorizar individualmente cada servidor.
Preciso migrar imediatamente do MCP legado?
Não necessariamente. Os SDKs suportam revisões de protocolo mais antigas por meio de negociação de versão, e os recursos descontinuados têm uma janela de suporte definida. Equipes de produção ainda devem começar os testes, pois o design sem estado altera as premissas sobre sessões, operações de longa duração e infraestrutura.
Ferramentas relacionadas
- Model Context Protocol: Documentação oficial da especificação, arquitetura, SDKs, extensões e guias para desenvolvedores do MCP.
- MCP TypeScript SDK: Implementação oficial em TypeScript para clientes e servidores MCP.
- MCP Python SDK: SDK oficial em Python e exemplos para desenvolvimento MCP.
- MCP Go SDK: Implementação oficial em Go, com suporte atual ao caminho de protocolo sem estado.
- MCP C# SDK: SDK oficial .NET, com documentação detalhada sobre modos sem estado, tarefas e compatibilidade.
- MCP Apps: Documentação oficial e SDK para interfaces interativas em hosts MCP.
- MCP Tasks: Documentação oficial para operações assíncronas de longa duração no MCP.
- [MCP Registry](https://registry.modelcontextprotocol.
io/): infraestrutura oficial de registro para descobrir servidores MCP publicados.
Links relacionados
- Visão geral do candidato a lançamento MCP 2026-07-28: explicação dos mantenedores oficiais sobre a refatoração sem estado, extensões, alterações de autenticação, cache e conteúdos descontinuados.
- Lançamentos do repositório de especificações MCP: histórico oficial de lançamentos no GitHub das revisões do protocolo.
- Roteiro MCP 2026: roteiro oficial abordando escalabilidade de transporte, comunicação entre agentes, governança e prontidão empresarial.
- Documentação oficial do MCP Apps: especificações, SDKs, exemplos e guias para desenvolvedores de aplicações MCP interativas.
- Extensão MCP Tasks:
Especificação oficial de tarefas, ciclo de vida, modelo de segurança e métodos suportados.
- Autorização gerenciada empresarial: documentação oficial sobre acesso MCP baseado em provedores de identidade centralizados.
- Túneis MCP da Anthropic: documentação da Anthropic sobre conexões MCP de rede privada em agentes gerenciados pelo Claude.
Resumo
A revisão MCP 2026-07-28 leva o protocolo a padrões de infraestrutura já amplamente adotados em grandes sistemas web. As solicitações tornam-se autossuficientes, as sessões em nível de protocolo desaparecem do novo formato online, o roteamento por gateways torna-se mais fácil e a escalabilidade horizontal comum não requer mais sessões MCP aderentes.
Ao mesmo tempo, o ecossistema também evolui. Os aplicativos MCP adicionam interfaces de usuário interativas, as tarefas suportam trabalho assíncrono persistente, a autorização gerenciada empresarial centraliza o acesso corporativo e os túneis MCP fornecem caminhos para servidores privados internos para usuários da plataforma Claude.
A migração não é simplesmente "remover o ID de sessão". As equipes precisam identificar dependências ocultas de estado, migrar o estado da aplicação para identificadores explícitos ou armazenamento persistente, testar MRTR e tarefas, atualizar autorizações, manter compatibilidade com clientes antigos e adicionar observabilidade adequada.
A mudança mais importante é em nível de arquitetura: o MCP está passando de um padrão de integração de agentes orientado a conexão para um protocolo sem estado e escalável que se adapta mais naturalmente à infraestrutura moderna de nuvem.
