Pela equipa da Kiwop · Agência Digital especializada em Desenvolvimento de Software e Inteligência Artificial aplicada · Publicado a 29 de julho de 2026 · Última atualização: 29 de julho de 2026
TL;DR — A 28 de julho de 2026 saiu a quinta revisão do MCP e é a que mais muda desde que o protocolo nasceu. Desaparecem as sessões e o handshake `initialize`: cada pedido viaja sozinho, com a sua versão e capacidades dentro de `_meta`. Os pedidos que antes o servidor iniciava (sampling, elicitation, roots) passam para o padrão multi round-trip. Chegam cabeçalhos obrigatórios para encaminhar sem abrir o corpo, listas cacheáveis e uma autorização mais dura. Se o teu servidor é stdio local, não há pressa. Se é remoto e guarda sessão, o redesenho começa hoje. O que ficou depreciado aguenta doze meses.
Há atualizações de protocolo que se resumem a uma linha de changelog e há outras que mudam como se faz o deploy do software que as fala. A revisão 2026-07-28 do Model Context Protocol é das segundas. Não acrescenta mais uma função a um protocolo que já conhecias: tira-lhe a memória. E quando um protocolo deixa de recordar, o que muda não é a API, é a arquitetura de tudo o que corre por baixo.
Em abril publicámos a comparação entre MCP, WebMCP e A2A e dissemos que o marco relevante seguinte seria a consolidação do transporte Streamable HTTP e a retirada do SSE legacy. As duas coisas cumpriram-se, e pelo caminho chegou bastante mais do que esperávamos. Este artigo é a leitura técnica do que muda exatamente, do que parte, e do que tem de fazer uma equipa que já tem servidores MCP em produção. Com a especificação na mão, não com o resumo do comunicado.
O que saiu a 28 de julho
O MCP nasceu em novembro de 2024 como forma de um modelo falar com ferramentas externas sem que cada integração fosse um adaptador à medida. Desde dezembro de 2025 já não é a Anthropic que o governa sozinha: o protocolo vive sob a Agentic AI Foundation, dentro da Linux Foundation, com Anthropic, OpenAI, Google, Microsoft, AWS, Block, Cloudflare e Bloomberg entre os membros. Essa governação partilhada explica o tom desta revisão, que se parece muito mais com uma norma de infraestrutura do que com a API de um fornecedor.
A revisão 2026-07-28 é a quinta da especificação e chega com duas novidades de processo que importam tanto como as mudanças técnicas. A primeira: existe finalmente uma política formal de ciclo de vida, com três estados (Ativo, Depreciado, Removido) e uma janela mínima de doze meses antes de algo desaparecer. A segunda: há um registo público de funções depreciadas com a data mais próxima em que cada uma pode cair. Para quem mantém software em produção, isso vale tanto como o protocolo em si, porque transforma o planeamento em algo que cabe num roadmap.
A mudança de fundo: da sessão ao pedido autónomo
Até esta revisão, falar MCP era abrir uma conversa. O cliente enviava initialize, o servidor respondia com as suas capacidades, o cliente confirmava com notifications/initialized e a partir daí ambos davam o contexto por sabido: que versão se falava, o que cada um sabia fazer, quem era quem. Sobre HTTP, essa conversa materializava-se num cabeçalho Mcp-Session-Id que o servidor emitia e o cliente repetia em cada chamada.
Tudo isso desapareceu.
O que desaparece
Vão-se o handshake initialize e a sua notificação notifications/initialized. Vai-se o cabeçalho Mcp-Session-Id e com ele o conceito de sessão ao nível do protocolo. Vai-se o endpoint GET do transporte Streamable HTTP, que era por onde o servidor abria o seu canal para falar por iniciativa própria. Vão-se resources/subscribe e resources/unsubscribe. Vão-se ping, logging/setLevel e notifications/roots/list_changed. E vai-se a retoma dos streams SSE: já não existem Last-Event-ID nem identificadores de evento, por isso um stream partido perde o pedido em curso e o cliente tem de o reenviar como pedido novo, com identificador novo.
É uma lista longa, e não é por acaso. Tudo o que saiu tinha a mesma propriedade: pressupunha que a ligação significava alguma coisa.
O que a substitui
Agora cada pedido explica-se a si próprio. A informação que antes se estabelecia uma vez no início viaja no campo _meta de cada chamada, com chaves reservadas pela especificação:
protocolVersion e clientCapabilities são obrigatórias em todo o pedido: se faltar alguma, o servidor tem de rejeitar com -32602 e, sobre HTTP, com um 400 Bad Request. clientInfo é recomendável, salvo se tiveres razão para não te identificares. Do lado do servidor, a recomendação é incluir io.modelcontextprotocol/serverInfo no _meta de cada resultado. Vale a pena ler bem a nota da especificação sobre estes dois campos: são autodeclarados, ninguém os verifica, e não devem servir para decisões de segurança nem para mudar comportamento.
A negociação de versão também muda de natureza. Já não há um momento de acordo: o cliente declara em cada pedido que versão fala e o servidor aceita ou rejeita cada um em separado. Se não a suportar, responde com UnsupportedProtocolVersionError (código -32022) e uma lista das versões que suporta, para o cliente tentar de novo com uma compatível.
Para os clientes que preferem saber de antemão há um método novo, server/discover, que devolve versões suportadas, capacidades e identidade numa só chamada. Os servidores têm de o implementar. Os clientes podem usá-lo ou não: é perfeitamente válido lançar a chamada que te interessa e tratar o erro de versão se aparecer.
Porque é que isto é boa notícia
A consequência prática é que um servidor MCP deixa de precisar de memória entre chamadas, e isso muda tudo no deploy. Sem sessão não é preciso sticky routing no balanceador, nem armazenamento partilhado entre instâncias, nem processos de longa duração. Um servidor MCP passa a ser o que qualquer equipa de plataforma sabe operar há anos: um endpoint HTTP sem estado que escala horizontalmente, faz deploy em serverless ou no edge, e cai e sobe sem arrastar nada.
A especificação é explícita em que nem sequer um processo stdio aberto deve ser entendido como uma conversa: o cliente pode intercalar pedidos sem relação pelo mesmo transporte, e o servidor não pode usar a identidade do processo como substituto da continuidade. Se o teu servidor precisa de estado real entre chamadas (uma sessão de trabalho, um carrinho, um contexto de análise), a via correta agora é explícita: emites tu um identificador e o cliente passa-o como argumento normal da ferramenta.
Multi Round-Trip Requests: o fim dos pedidos do servidor
A segunda grande mudança é a que mais código vai mexer nos servidores que fazem algo interessante.
Até agora, quando um servidor precisava de algo do cliente a meio de uma operação (uma resposta do utilizador via elicitation, uma chamada ao modelo via sampling, a lista de diretórios via roots) abria o seu próprio pedido JSON-RPC em sentido contrário. Isso obrigava a manter um canal aberto e, na prática, a que a mesma instância tratasse toda a operação.
O padrão novo chama-se Multi Round-Trip Requests e inverte o fluxo: o servidor não pergunta, o servidor termina o pedido a pedir. Devolve um resultado com resultType: "input_required" que contém um mapa inputRequests com o que precisa, e opcionalmente um requestState opaco. O cliente reúne essa informação e repete o pedido original com as respostas em inputResponses e o requestState devolvido tal e qual.
Três detalhes que passam ao lado numa leitura rápida e que depois custam uma tarde de depuração. O identificador JSON-RPC da nova tentativa tem de ser diferente do do pedido inicial, porque são pedidos independentes. O requestState é opaco para o cliente, que não o pode inspecionar nem modificar, mas é entrada controlada pelo atacante do ponto de vista do servidor: se influencia autorização ou lógica de negócio, tem de ser protegido com HMAC ou AEAD, com validade curta, ligado ao principal autenticado e ao pedido de origem, e rejeitado quando não verifica. E InputRequiredResult só pode ser devolvido em prompts/get, resources/read e tools/call: em mais lado nenhum.
Como efeito colateral, todos os resultados levam agora um campo resultType obrigatório, com "complete" para o caso normal. Se falares com um servidor de uma revisão anterior que não o inclui, interpreta-se como "complete".
O resto das mudanças que vais notar
Cabeçalhos obrigatórios para encaminhar. Todo o pedido POST sobre Streamable HTTP tem de levar Mcp-Method com o método, e Mcp-Name com o nome da ferramenta ou o URI do recurso em tools/call, resources/read e prompts/get. Soa a burocracia até pensares em quem está à frente do teu servidor: agora um balanceador, uma gateway ou uma WAF pode encaminhar, medir e aplicar políticas sem abrir o corpo JSON. O servidor é obrigado a validar que cabeçalho e corpo coincidem, e a rejeitar com 400 e HeaderMismatch (-32020) se não. Há até um mecanismo para levar parâmetros concretos de uma ferramenta a cabeçalhos (x-mcp-header), pensado para coisas como encaminhar por região.
Listas cacheáveis. Os resultados de tools/list, prompts/list, resources/list, resources/read e resources/templates/list levam agora ttlMs e cacheScope (public ou private). O primeiro é uma pista de frescura para o cliente cachear em vez de perguntar; o segundo diz se um intermediário partilhado o pode guardar. E há uma recomendação pequena com efeito grande: devolver as ferramentas em tools/list por ordem determinista, porque assim o prompt do modelo não muda entre chamadas e a cache de prompt do LLM acerta mais.
Subscrições. O que antes se fazia abrindo um GET pede-se agora com subscriptions/listen, um pedido cuja resposta é um stream que fica aberto. O cliente escolhe a que subscreve (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions) e o servidor etiqueta cada notificação com io.modelcontextprotocol/subscriptionId. As notificações de progresso e de log continuam a viajar pelo stream do pedido a que pertencem, não por aqui.
Autorização. Três apertos. Os servidores de autorização deveriam incluir o parâmetro iss segundo a RFC 9207, e o cliente tem de validá-lo contra o issuer registado antes de trocar o código. As credenciais ficam ligadas ao issuer que as emitiu: guardadas indexadas por ele, nunca reutilizadas com outro, e com novo registo se o servidor de autorização mudar. E o registo dinâmico de clientes (DCR, RFC 7591) fica depreciado a favor dos Client ID Metadata Documents, embora continue disponível para autorizações que ainda não suportem CIMD.
Erros. Há finalmente uma política de atribuição de códigos: de -32000 a -32019 fica como zona herdada que ninguém novo deveria usar, e de -32020 a -32099 é território exclusivo da especificação. Os três códigos novos são HeaderMismatch (-32020), MissingRequiredClientCapability (-32021) e UnsupportedProtocolVersion (-32022). Além disso, o erro de recurso não encontrado passa de -32002 para -32602, embora os clientes devam continuar a aceitar o antigo de servidores anteriores.
Tasks fora do core. As tarefas experimentais saem do protocolo base e passam a ser uma extensão oficial (io.modelcontextprotocol/tasks), com polling via tasks/get em vez do tasks/result bloqueante. Na mesma linha, capacidades de cliente e servidor ganham um campo extensions para negociar tudo o que fique fora do núcleo.
O que parte e o que não
Esta é a tabela que convém ter à frente antes de mexer em nada. A especificação chama modernas às versões que levam os metadados em cada pedido (de 2026-07-28 em diante) e legacy às que usam handshake (2025-11-25 e anteriores).
A leitura importante está nas duas linhas que falham: um cliente antigo não pode falar com um servidor só-moderno, e não há nada que possa fazer. Por isso a especificação pede que um servidor que só fale moderno inclua, no erro com que responde a um initialize, as versões que suporta: pode ser o único diagnóstico que o utilizador desse cliente chegue a ver.
Um servidor que queira servir os dois mundos pode fazê-lo, e decide pela forma como o cliente abre: se o pedido traz _meta moderno, serve-o sem estado; se chega um initialize, entra em modo antigo. Um cliente que queira o mesmo deteta a era do servidor por transporte: em stdio, sondando com server/discover e caindo em initialize perante qualquer erro que não seja um erro moderno reconhecível; sobre HTTP, lançando um pedido moderno e olhando o corpo do 400 antes de decidir. Esse resultado é cacheado por servidor, não por pedido.
O que tens de mexer, conforme o teu caso
Se usas servidores MCP por stdio em local, que é o caso da maioria dos assistentes pessoais e de quase tudo o que corre dentro de um IDE, não há pressa. O teu cliente e os teus servidores negoceiam a versão que ambos falam, e a revisão anterior continua válida. O que toca é atualizar o SDK quando fores mexer nesse servidor por qualquer outro motivo, não montar uma migração à parte. É exatamente o que vamos fazer com os servidores do assistente pessoal que construímos com Claude Code.
Se tens um servidor remoto que guarda sessão, aqui há trabalho de arquitetura, e é agora. Não é trocar uma biblioteca: é tirar o estado do processo. Inventaria o que guardas hoje entre chamadas e decide, para cada coisa, se desaparece (porque o cliente já a envia em _meta), se passa a ser um handle explícito que o cliente leva como argumento, ou se vai para um armazenamento externo indexado por esse handle. Tudo o que dependa de duas chamadas caírem na mesma instância podes dar por morto. A recompensa é real: no fim, o teu servidor corre em serverless.
Se o teu servidor abre pedidos ao cliente (sampling, elicitation ou roots), tens de refazer esse fluxo com MRTR. É a mudança que mais lógica mexe, porque passas de um modelo conversacional para um em que cada tentativa é autónoma e o contexto viaja no requestState que tu assinas e verificas. Começa por aí, não pelo resto.
Se vais começar um servidor MCP novo, fá-lo diretamente sobre 2026-07-28. Não há razão nenhuma para construir hoje sobre o modelo com sessões, e há uma para não o fazer: dentro de doze meses estarias a migrar o que acabaste de escrever.
Se manténs um cliente, o trabalho é diferente e provavelmente maior: tens de suportar as duas eras durante bastante tempo, cachear o que cada servidor fala e gerir a degradação com critério. Os quatro SDK de nível 1 (TypeScript, Python, Go e C#) já trazem suporte da revisão nova, e o de Rust vai em beta, por isso boa parte disto vem feito se andares a par.
O calendário real
O melhor da política de ciclo de vida é que se pode planear com datas, não com rumores. Isto é o que está depreciado e até quando aguenta:
Atenção à última linha, que é a que vai mesmo com pressa. O transporte HTTP+SSE estava depreciado desde março de 2025 e entra agora formalmente na política, com uma janela de apenas três meses. Se te resta algo a falar por aí, essa é a migração urgente, não as outras.
Que algo seja elegível para retirada não significa que se retire nesse dia: a decisão é dos mantenedores em cada release e pode chegar mais tarde. Mas é a data com que planear.
O que faríamos nós
Três critérios que aplicamos a esta classe de mudanças, e que aqui valem especialmente.
Não migres por estares a par, migra por uma razão. Um servidor stdio que funciona não precisa de ser tocado esta semana. O custo de migrar sem motivo não é só o tempo: é que introduzes risco em algo que já ia bem. A janela de doze meses existe para ser usada.
O que é urgente é o que se desenha agora. Qualquer servidor MCP novo, e qualquer plataforma que vá abrir a sua API a agentes, desenha-se sem estado desde o primeiro dia. É a decisão que mais caro sai mudar depois, porque não é uma biblioteca, é como repartes o trabalho entre instâncias. No nosso caso, isto afeta diretamente como o Nexo vai expor as suas capacidades aos agentes dos seus clientes: o desenho faz-se contra a revisão nova, não contra a que já conhecíamos.
Cuidado com construir produto sobre superfícies experimentais. Aprendemo-lo com o WebMCP: montámos sobre um origin trial do Chrome e uma mudança do lado do navegador partiu-nos a navegação do site, com os nossos health checks a verde. O MCP 2026-07-28 não é experimental, mas a lição aplica-se igual: quando adotares algo acabado de publicar, tem claro como o desligas se correr mal, e comprova o resultado com mãos e olhos, não só com um código 200.
Perguntas frequentes
Parte-se alguma coisa hoje se não fizer nada? Não, se o teu cliente e os teus servidores falarem a mesma revisão. O que já funcionava continua a funcionar, e a revisão anterior mantém suporte. Parte-se quando misturas eras: um cliente antigo contra um servidor que só fala a nova, ou ao contrário.
Quanto tempo tenho mesmo? Doze meses no mínimo para Roots, Sampling, Logging e o registo dinâmico de clientes, contados desde 28 de julho de 2026. A exceção é o transporte HTTP+SSE, que pode cair três meses depois de a sua proposta ser final.
Tenho de implementar `server/discover`? Se escreves um servidor, sim: é obrigatório. Se escreves um cliente, não: podes lançar a chamada que precisares e tratar o erro de versão se aparecer. Em stdio é além disso a forma recomendada de detetar se o servidor à frente é moderno ou antigo.
O que faço com o estado que guardava na sessão? Tira-o do processo. O que era contexto de protocolo já viaja no _meta de cada pedido. O que é estado de aplicação passa a ser um identificador explícito que tu emites e o cliente te devolve como argumento, com o dado real num armazenamento externo se for preciso.
Isto afeta o WebMCP? Não. O WebMCP é a proposta do navegador, impulsionada pelo Chrome e trabalhada no W3C, e segue o seu próprio caminho. É outra camada: o MCP liga o agente a ferramentas de servidor, o WebMCP expõe ações a partir do site que o utilizador tem aberto.
E os clientes de desktop tipo Claude ou ChatGPT? Os produtos vão incorporando a revisão nova ao seu ritmo, e nenhum publicou datas concretas. Entretanto negoceiam versão com cada servidor, por isso a convivência está prevista por desenho.
Conclusão
A leitura curta de 2026-07-28 é que o MCP deixou de se comportar como uma conversa para se comportar como uma API. Cada pedido explica-se sozinho, o servidor não recorda, e tudo o que precisava de memória foi redesenhado ou saiu. Isso torna o protocolo mais aborrecido de ler e muitíssimo mais fácil de operar, que é exatamente o que precisa algo que aspira a ser infraestrutura.
Para a maioria das equipas a resposta prática desta semana é não fazer nada urgente e planear bem. Para quem tenha servidores remotos com sessão, ou esteja prestes a desenhar como abre a sua plataforma a agentes, a resposta é a contrária: o trabalho começa agora, e começa por tirar o estado do meio.
Se estás no segundo caso e queres confrontar o desenho com quem já o fez, falamos. Levamos dois anos a construir sobre LLM em produção, temos servidores MCP a correr e pagámos a fatura de adotar coisas antes de tempo.
