MCP ganha núcleo stateless: o protocolo parou de improvisar

No dia 21 de maio, os mantenedores do MCP (David Soria Parra e Den Delimarsky) publicaram o release candidate 2026-07-28 do protocolo. O post chama de “a maior revisão desde o lançamento”. É verdade, e ainda assim subestima o que mudou. O Model Context Protocol acaba de deixar de ser artefato de pesquisa que se tolerava em produção e passou a ser uma superfície avaliável que pode entrar em contrato com fornecedor.

Os números fazem boa parte do trabalho. Seis SEPs (Specification Enhancement Proposals) tratam de statelessness. Outros seis fortalecem a camada de autorização. Os mantenedores fixaram uma janela mínima de 12 meses entre deprecação e remoção. Três primitivos herdados do design original de 2024 (Roots, Sampling, Logging) estão formalmente deprecados. Duas extensões (MCP Apps e Tasks) entram como os primeiros exemplos oficiais do novo modelo de extensão por DNS reverso. Há uma janela de 10 semanas de validação antes da spec final em 28 de julho.

Os times que passaram os últimos nove meses argumentando que o MCP “não está pronto para produção” agora têm uma data concreta em que esse argumento deixa de valer.

A inflexão stateless

A mudança mais importante é estrutural. Até este RC, um servidor MCP carregava estado de sessão. Toda requisição de um cliente precisava cair na mesma instância, porque aquela instância lembrava quem era o cliente e quais ferramentas já tinham sido negociadas. Esse fato isolado ditava todo o padrão de deployment a jusante. Sticky sessions no load balancer. Afinidade de sessão na service mesh. Lógica customizada no CDN para honrar cookies de sessão. Um time que quisesse rodar MCP atrás de DNS round-robin simples na frente de três containers Lambda não conseguia, porque a segunda requisição cairia num container diferente e a negociação teria sumido.

O núcleo stateless resolve isso no nível do protocolo. Estado agora mora na aplicação, onde sempre deveria estar. Um servidor MCP na spec 2026-07-28 é um serviço HTTP stateless. Você pode colocá-lo atrás de qualquer load balancer que distribua requisições de forma aleatória. Você pode cachear respostas na borda. Você pode escalar horizontalmente sem coordenação. Você pode fazer o deploy do mesmo jeito que faz com qualquer outro serviço HTTP interno, sem infraestrutura específica de protocolo no caminho.

Essa é a mudança que transforma o MCP de algo que o seu time de plataforma tinha que planejar em algo que o seu time de plataforma pode ignorar. Para uma empresa que opera service mesh, API gateway e CDN, “parece HTTP” é o jogo inteiro. O protocolo acabou de ganhar o direito de rodar na infraestrutura que você já opera.

Foram seis SEPs para entregar isso. Vale entender por que precisou de seis. Transporte stateless não é só “remover o ID da sessão”. Exigiu repensar como capacidades de ferramentas são negociadas, como subscrições em recursos de longa duração funcionam sem conexão aberta, como tokens de autorização são escopados por requisição em vez de por sessão, e como o cliente sabe o que o servidor oferece sem ter que perguntar a cada vez. Cada uma dessas frentes é uma proposta separada, com revisão separada. Seis SEPs é o tamanho da faxina.

Autorização deixa de ser esboço

O segundo agrupamento (outros seis SEPs) fecha a história de autorização. Até este RC, autorização no MCP era intenção documentada. A spec dizia “use OAuth 2.1”. As implementações faziam mais ou menos isso, com variação suficiente para transformar uma revisão de segurança em projeto de pesquisa.

O RC alinha o protocolo com OAuth e OIDC no nível em que um time de segurança realmente se importa. Validação de token issuer (iss) agora está na spec, não na seção de orientação. Semântica de escopo está definida. Vinculação de audiência do token está definida. Os mantenedores removeram explicitamente a ambiguidade sobre qual token pode ser usado por qual cliente contra qual servidor. A intenção é que a história de autorização de um servidor MCP seja auditável contra o mesmo playbook que os seus fornecedores SaaS atuais usam.

Essa é a mudança que permite ao CISO aprovar sem precisar escrever uma aceitação de risco customizada. Quando o fluxo OAuth contra o seu servidor MCP é indistinguível do fluxo OAuth contra o seu CRM, valem os mesmos controles: o mesmo provedor de identidade, o mesmo inventário de escopos, a mesma política de tempo de vida de token, o mesmo caminho de revogação. O protocolo parou de exigir que você invente controles novos.

A política de deprecação é a vitória de procurement

Soterrada sob as mudanças de destaque está a peça que mais importa para procurement: uma política formal de deprecação com janela mínima de 12 meses entre anúncio e remoção. Roots, Sampling e Logging são os primeiros primitivos a entrar nessa janela. Estão saindo porque eram pouco usados, mal escopados ou duplicados por mecanismos melhores (Tasks substitui trabalho de longa duração; Apps substitui as preocupações com superfície de UI). O ponto não é quais primitivos estão saindo. O ponto é o calendário.

Doze meses é tempo suficiente para um fornecedor atualizar um SDK, lançar uma nova release e dar caminho de migração aos clientes. Também é tempo suficiente para um time de procurement escrever a cláusula contratual que diz: “Se um primitivo do qual o seu servidor depende for deprecado, você tem nove meses a partir do anúncio para entregar atualização compatível, e cabe remediação caso contrário.” Até a semana passada, essa cláusula era impossível de escrever, porque não havia cadência definida de deprecação para apontar. Agora há.

A janela de 12 meses é também o que torna seguro colocar servidores MCP em ambientes que têm ciclos de refresh de software de 24 meses. Dois ciclos de refresh cobrem um ciclo de deprecação com folga. O protocolo virou deployável em setores regulados que estavam esperando exatamente esse compromisso.

Extensões ganham namespace

MCP Apps e Tasks entram como as duas primeiras extensões sob um esquema de nomeação por DNS reverso. Apps traz a preocupação com superfície de UI para dentro do protocolo (o cliente pode renderizar UI fornecida pelo servidor de forma controlada). Tasks traz trabalho de longa duração para dentro do protocolo (o servidor pode devolver um handle de tarefa, o cliente pode fazer polling ou subscrever, o trabalho sobrevive a uma desconexão). As duas foram validadas em implementações reais ao longo dos últimos nove meses. As duas agora têm casa estável na spec.

O esquema de DNS reverso importa mais do que as duas extensões específicas. Significa que um fornecedor pode entregar com.acme.mcp.coisa-proprietaria como extensão reconhecida, e um cliente pode anunciar que suporta org.modelcontextprotocol.apps sem confusão. O namespace é o mecanismo que permite ao protocolo crescer sem fragmentar. Até agora, toda feature específica de fornecedor era ou uma extensão privada que ninguém mais conseguia descobrir, ou uma proposta para mudar o core da spec. O caminho do DNS reverso é o meio termo, e é aquele que todo ecossistema de protocolo saudável acabou adotando.

O que fazer nas próximas 10 semanas

A janela de 10 semanas de validação antes de 28 de julho é quando você consegue influenciar a forma final da spec. Três ações merecem agendamento.

Primeiro, audite os seus deployments atuais de MCP em busca de premissas stateful. Se você tem configuração de sticky session em load balancer por causa de MCP, marque para remoção. Se tem política de service mesh que prende clientes a instâncias, o mesmo. A migração não é automática, mas a faxina é direta e a simplificação operacional é permanente.

Segundo, rode uma revisão de fluxo de token contra os seus servidores MCP sob as novas regras de autorização. A validação de iss, a semântica de escopo e a vinculação de audiência são os três pontos em que as implementações atuais têm mais chance de divergir da spec. Uma revisão de 60 minutos com o seu time de identidade já mostra o que precisa mudar.

Terceiro, escreva a cláusula de deprecação no próximo contrato de fornecedor MCP. A janela de 12 meses é o artefato que torna a cláusula defensável. Se você está fechando contrato neste trimestre sem essa cláusula, está fechando um contrato que vence no dia em que um primitivo usado pelo seu fornecedor for removido.

O RC do MCP não é release de feature. É o momento em que o protocolo parou de ser algo que você adota por fé e passou a ser algo que você consegue avaliar. Os fornecedores que estavam esperando esse momento para levar a sério vão ser os que se moverem rápido no Q3. Os compradores que continuarem tratando MCP como pesquisa vão ser os que estarão assinando cheque de remediação em 2027.

Fontes

Model Context Protocol. “The 2026-07-28 MCP Specification Release Candidate.” Maio de 2026.

A Victorino apoia times de procurement e de plataforma a transformar mudanças de protocolo em critérios de avaliação de fornecedores antes que virem padrão: contato@victorino.com.br | www.victorino.com.br