O Model Context Protocol atingiu um importante marco de infraestrutura: sua revisão de 2026/07/28 move o protocolo em direção a um núcleo sem estado. Para equipes que constroem sistemas de agentes, servidores de ferramentas, integrações IDE ou camadas de orquestração multimodelo, esta não é uma atualização cosmética de especificações. Ele altera suposições sobre sessões, inicialização, escalabilidade, compatibilidade e governança.

O candidato à versão MCP descreveu a especificação de 28 de julho como a adição de um núcleo de protocolo sem estado, uma estrutura de extensões, tarefas, MCP aplicativos, reforço de autorização e uma política formal de descontinuação. O blog oficial MCP também alertou que a versão contém alterações importantes. GitHub, que opera uma das implementações de servidor MCP mais visíveis, disse antes do lançamento final que seu servidor MCP já suportava a nova especificação e descreveu o protocolo como "tornando-se sem estado" em 28 de julho.

O significado prático é direto: MCP está sendo moldado menos como uma camada de integração local com sessões pesadas e mais como um protocolo em escala de Internet para acesso remoto a ferramentas. Isso é importante porque os sistemas de agentes não estão mais confinados às ferramentas de desenvolvimento de desktop. Cada vez mais, eles são executados em serviços de nuvem, sistemas de CI, fluxos de trabalho de suporte ao cliente, rastreadores de problemas e plataformas de automação empresarial.

O que mudou em MCP

A mudança principal é a mudança para um núcleo de protocolo sem estado. O changelog de GitHub diz que o novo núcleo remove sessões e inicializa, com o objetivo de tornar as implantações MCP remotas mais fáceis de escalar. Essa é uma mudança arquitetônica significativa. Protocolos com estado podem funcionar bem para ferramentas locais e ambientes controlados, mas complicam o escalonamento horizontal, a execução sem servidor, o failover, a implantação de borda e o balanceamento de carga.

Um núcleo sem estado dá aos implementadores mais liberdade para executar MCP servidores por trás da infraestrutura da Web comum. As solicitações podem ser distribuídas entre instâncias sem preservar uma sessão de longa duração em um back-end específico. Para grandes organizações, isso pode reduzir a complexidade operacional. Para equipes menores, isso pode facilitar a implantação de MCP servidores hospedados usando computação gerenciada em vez de infraestrutura personalizada de longa execução.

A versão mais ampla de 28/07/2026 também introduz uma estrutura de extensões e tarefas, de acordo com os materiais do candidato ao lançamento. Essas adições sugerem que MCP está se tornando mais modular e mais explícito sobre trabalhos de longa duração. MCP O fortalecimento de aplicativos e autorização aponta na mesma direção: o protocolo está amadurecendo desde a integração inicial do ecossistema até uma camada mais formal para interação entre agente e ferramenta.

O custo desse amadurecimento é o trabalho de compatibilidade. O blog MCP caracterizou o lançamento como um lançamento com alterações significativas, e os materiais TypeScript e C# SDK publicados em torno da revisão focam no suporte à migração e nos conceitos sem estado. Qualquer equipe que opere um servidor MCP, incorpore MCP em uma extensão IDE ou encaminhe chamadas de agente por meio de infraestrutura interna deve tratar a revisão como um evento de engenharia em vez de uma atualização de padrões em segundo plano.

Por que a ausência de estado MCP é importante para desenvolvedores e operadores

As ferramentas de agente têm um problema de dimensionamento que parece diferente do dimensionamento API comum. Uma única solicitação de usuário pode acionar muitas chamadas de ferramentas, giros de modelos, novas tentativas, leituras de arquivos, consultas de pesquisa e etapas de aprovação. Quando o protocolo da ferramenta assume sessões duráveis, os operadores de produção devem preservar o estado entre essas interações ou criar soluções alternativas em torno do protocolo.

Ao remover sessões do núcleo, MCP se adapta melhor a ambientes onde as cargas de trabalho do agente são intermitentes, distribuídas e assíncronas. Funções sem servidor, trabalhadores de borda, implantações de Kubernetes e sistemas multirregionais se beneficiam quando as solicitações podem ser tratadas de forma independente.Isso não elimina o estado dos aplicativos do agente; ele move o estado para bancos de dados de aplicativos, filas de tarefas, sistemas de identidade ou camadas de fluxo de trabalho explícitas, em vez de incorporá-lo ao núcleo do protocolo.

Para os desenvolvedores, a mudança deve eventualmente facilitar o consumo de servidores de ferramentas remotas. Para equipes de plataforma, isso pode simplificar a observabilidade e o planejamento de capacidade. Em vez de depurar o comportamento opaco de afinidade de sessão, os operadores podem se concentrar em rastreamentos em nível de solicitação, latência de chamada de ferramenta, decisões de autorização e padrões de erro.

Há também um ângulo de governança. À medida que MCP se torna mais comum em assistentes de codificação e agentes corporativos, as empresas precisarão de políticas sobre quais ferramentas os agentes podem chamar, quais dados eles podem acessar e quais usuários ou serviços têm permissão para invocá-los. Authorization a proteção na nova revisão não é, portanto, acidental. Isso reflete a realidade de que o acesso a ferramentas é agora um limite de segurança, não apenas uma conveniência para o desenvolvedor.

Quem é afetado

Os grupos mais diretamente afetados são MCP mantenedores de servidores, SDK usuários, equipes de plataformas de agentes e organizações que expõem ferramentas internas a agentes de IA. Se um servidor depender do comportamento da sessão ou de fluxos de inicialização mais antigos, ele precisará de testes em relação à nova especificação. Se um aplicativo oferecer suporte a diversas MCP versões, ele poderá precisar de negociação de versão, camadas de compatibilidade ou um plano de migração em fases.

Fornecedores de IDE e ferramentas para desenvolvedores também estão no escopo. MCP está aparecendo cada vez mais junto com agentes de codificação, agentes personalizados e recursos de gerenciamento de modelo. Um núcleo de protocolo sem estado torna mais fácil para esses produtos chamarem ferramentas remotas de maneira confiável, mas somente se suas integrações acompanharem as especificações.

As empresas que usam automação de agentes devem prestar atenção, mesmo que nunca tenham lido a especificação MCP. A mudança pode afetar a confiabilidade dos agentes que se conectam a repositórios, sistemas de tickets, bancos de dados, bases de conhecimento internas ou ferramentas de implantação. Durante as janelas de migração, os modos de falha prováveis ​​não são apenas interrupções óbvias. Eles podem incluir recursos de ferramenta ausentes, comportamento de autenticação alterado ou agentes que seguem caminhos diferentes porque um servidor de ferramentas não se comporta mais conforme o esperado.

Para um gateway AI API como Model Gate, a conexão é prática. Uma IA unificada API está cada vez mais próxima do roteamento de modelos, API do gerenciamento de chaves, da análise de uso e da governança API da equipe. À medida que os sistemas de agente adicionam MCP chamadas de ferramenta além das chamadas de modelo comuns, as camadas de gateway e de observabilidade precisarão levar em conta ambos os lados do fluxo de trabalho: qual modelo foi usado, quais ferramentas foram invocadas, quanto custam, quem as autorizou e onde ocorreram falhas.

Prioridades de migração e questões abertas

A primeira prioridade de migração é o teste de compatibilidade. As equipes devem inventariar MCP clientes e servidores, identificar dependências em sessões ou inicializar o comportamento e testar os SDKs de 28/07/2026 ou materiais de conformidade, quando disponíveis. Os sistemas de produção devem preparar a atualização, especialmente se os agentes executarem ações com efeitos colaterais, como criar solicitações pull, modificar problemas, consultar dados de clientes ou executar fluxos de trabalho de implantação.

A segunda prioridade é a observabilidade. A infraestrutura sem estado pode ser mais fácil de escalar, mas os sistemas de agentes distribuídos ainda precisam de IDs de correlação, captura de rastreamento, logs de solicitação e eventos de política. Sem isso, as equipes podem trocar a complexidade da sessão pela complexidade da depuração. A análise de uso deve distinguir entre chamadas de modelo e chamadas de ferramenta, especialmente quando os fluxos de trabalho do agente são cobrados, têm taxa limitada ou são auditados pela equipe.

A terceira prioridade é a revisão da autorização. Se a nova especificação endurecer a semântica de autorização, os implementadores não deverão simplesmente portar antigas suposições de acesso para a nova versão. Eles devem verificar novamente os escopos de token, a delegação de usuários, as contas de serviço, os logs de auditoria e o comportamento de negação.O acesso à ferramenta deve ter privilégios mínimos por padrão, especialmente para implantações MCP remotas.

Alguns detalhes ainda valem a pena ser verificados antes que as organizações tomem decisões de design irreversíveis. A pesquisa disponível para este artigo incluiu o release candidate, a página de especificações, SDK materiais de migração e a nota de implementação de GitHub. O texto normativo final da especificação 2026-07-28 deve ser revisado diretamente antes de citar os requisitos exatos do protocolo em padrões internos ou na documentação do cliente.

Mesmo com essa ressalva, a direção é clara. MCP está se tornando um protocolo mais orientado à produção para infraestrutura de agente. O núcleo sem estado deve facilitar a escalabilidade das implantações remotas, mas também força o ecossistema a eliminar suposições de implementações anteriores. Para equipes que estão construindo com agentes, esse é o tipo de mudança de protocolo que merece um ticket de sprint, e não apenas um marcador.