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, escalonamento, compatibilidade e governança.

O release candidate do 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, aplicativos MCP, fortalecimento de autorização e uma política formal de descontinuação. O blog oficial do MCP também alertou que o lançamento contém alterações importantes. O 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 é simples: o MCP está sendo moldado menos como uma camada de integração local com muitas sessões 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 no MCP

A principal mudança é a mudança para um núcleo de protocolo sem estado. O changelog do GitHub diz que o novo núcleo remove sessões e inicializa, com o objetivo de tornar as implantações remotas de MCP 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 servidores MCP por trás de uma infraestrutura 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 servidores MCP 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 o MCP está se tornando mais modular e mais explícito em relação ao trabalho de longa duração. Os aplicativos MCP e o fortalecimento da autorização apontam na mesma direção: o protocolo está amadurecendo desde a colagem 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 do 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 o 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 o MCP sem estado é importante para desenvolvedores e operadores

As ferramentas de agente têm um problema de escalabilidade que parece diferente da escalação de API comum. Uma única solicitação do 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, o MCP se adapta melhor a ambientes onde as cargas de trabalho dos agentes 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 no núcleo do protocolo.

Para os desenvolvedores, a mudança deve eventualmente tornar os servidores de ferramentas remotos mais fáceis de consumir. 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 o 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. O endurecimento da autorização na nova revisão não é, portanto, acidental.Isso reflete a realidade de que o acesso às ferramentas é agora um limite de segurança, não apenas uma conveniência para os desenvolvedores.

Quem é afetado

Os grupos mais diretamente afetados são os mantenedores de servidores MCP, usuários de SDK, 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 versões do MCP, 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. O MCP aparece 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 ferramentas 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 de API de IA como o Model Gate, a conexão é prática. Uma API de IA unificada está cada vez mais próxima do roteamento de modelos, gerenciamento de chaves de API, análise de uso e governança de API de equipe. À medida que os sistemas de agentes adicionam chamadas de ferramentas MCP 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 em aberto

A primeira prioridade de migração são os testes de compatibilidade. As equipes devem inventariar clientes e servidores MCP, identificar dependências em sessões ou inicializar o comportamento e testar os SDKs 2026-07-28 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 dos agentes são cobrados, têm taxas limitadas 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 remotas de MCP.

Alguns detalhes ainda merecem 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, os materiais de migração do SDK e a nota de implementação do GitHub. O texto normativo final da especificação 2026-07-28 deve ser revisado diretamente antes de citar os requisitos exatos do protocolo nos padrões internos ou na documentação do cliente.

Mesmo com essa ressalva, a direção é clara. O MCP está se tornando um protocolo mais orientado à produção para infraestrutura de agentes. 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 trabalham com agentes, esse é o tipo de mudança de protocolo que merece um ticket de sprint, e não apenas um marcador.