O MCP foi feito para uma pessoa sentada à frente de um portátil. O roteiro de 2026 serve para a retirar

As quatro suposições sobre as quais o MCP foi construído — uma pessoa a carregar em Permitir, uma pessoa à espera de alguns segundos, um catálogo de ferramentas curto o suficiente para ser lido, um subprocesso no portátil dessa pessoa — face aos pontos do roteiro de 2026 que substituem cada uma delas: identidade de agentes e DPoP, tarefas e eventos iniciados pelo servidor, descoberta progressiva e HTTP sobre stdio — Nenhum destes pontos é uma funcionalidade nova. Cada um marca um sítio onde o protocolo contava com uma pessoa presente, e onde a produção descobriu que não estava lá ninguém.

O roteiro do Model Context Protocol foi atualizado a 22 de agosto de 2026 e, enterrada na terceira área prioritária, está a frase mais esclarecedora que se escreveu este ano sobre infraestrutura de agentes:

A autorização do MCP parte do princípio de que há uma pessoa com um navegador no momento do consentimento.

Leiam-se as outras quatro áreas prioritárias depois dessa e deixam de parecer uma lista de funcionalidades. São um só projeto com cinco frentes: o protocolo foi desenhado para alguém sentado à frente de um portátil, e a produção não se cansa de descobrir que não está lá ninguém.

Vale uma tarde de atenção, porque cada ponto do roteiro é algo que já resolve à mão — normalmente mal, e normalmente sem ter reparado que estava a tomar uma decisão.

1. As cinco áreas prioritárias, e o que são na verdade

O roteiro é explícito quanto a ser um documento de priorização e não um calendário de entregas: as SEP — Specification Enhancement Proposals — que caem dentro destas áreas "têm revisão acelerada e as melhores hipóteses de serem aceites". Tudo o resto espera.

As cinco áreas, e a suposição humana que cada uma elimina

Áreas prioritárias do roteiro de 2026

Primitivas de mensagens agênticas — assumiam que alguém esperava uns segundos por uma resposta. Tarefas, subscrições e notificações de progresso têm agora de compor-se num único ciclo de vida.
Unificação do transporte nativo HTTP — assumia um subprocesso na máquina dessa pessoa. O objetivo é um só modelo de transporte, com o stdio a tornar-se HTTP falado sobre stdin/stdout.
Identidade de agentes e segurança para empresas — assumia o ecrã de consentimento do navegador. Quem chama é agora uma carga de trabalho na cloud com identidade própria, a agir por um utilizador ausente.
Primitivas melhoradas — assumiam um catálogo curto o suficiente para ser lido de uma vez, e uma forma de resultado do tools/call que toda a gente interpretaria da mesma maneira. Nenhuma das duas se aguentou.
Melhor experiência de desenvolvimento nos SDK — assumia que SDK mantidos à mão acompanhariam o ritmo da especificação. A experiência passa por gerá-los a partir dela.

As primeiras quatro são arquitetura. A quinta trata de como as outras quatro lhe chegam, o que pesa mais do que parece: é a diferença entre uma alteração da especificação aterrar no seu SDK em semanas ou em meses.

2. A parte que já saiu, e que pode já o estar a afetar

Antes do roteiro houve uma versão. A especificação 2026-07-28 tornou o núcleo do protocolo sem estado, e essa é a alteração com maior probabilidade de tocar num sistema que tenha hoje a correr.

Em concreto, eliminou o aperto de mão initialize/initialized e o cabeçalho Mcp-Session-Id. Cada pedido transporta agora a sua própria versão de protocolo, identidade de cliente e capacidades em _meta. A consequência, nas palavras da própria especificação, é que qualquer pedido pode aterrar em qualquer instância do servidor por trás de um balanceador de carga round-robin vulgar, sem armazenamento partilhado.

Porque deve um fundador ligar à eliminação de um aperto de mão

As sessões com estado brigam com os balanceadores de carga. Se colocou um servidor MCP remoto em mais do que uma instância, ou fixou sessões, ou partilhou estado através do Redis, ou manteve em silêncio uma só máquina à espera de que corresse bem. As três coisas são remendos para uma suposição que acaba de ser retirada do protocolo. Se construiu um desses remendos, passou a ser peso morto em vez de complexidade necessária, e convém apagá-lo de propósito em vez de o arrastar para a coisa seguinte que construir.

Na mesma versão saíram outras três coisas fáceis de ignorar e de utilidade imediata:

Confirmações a meio da chamada sem ligação aberta

SEP-2322

Os pedidos de várias voltas substituem os pedidos iniciados pelo servidor que exigiam um fluxo aberto. O servidor devolve resultType: "input_required" e o cliente repete a chamada original com as respostas em inputResponses. Aprovação humana, sem que a ligação seja aquilo que sustenta o estado.

Encaminhar sem ler o corpo

SEP-2243

Os pedidos transportam agora os cabeçalhos HTTP Mcp-Method e Mcp-Name, para que gateways, limitadores de taxa e WAF possam encaminhar e medir por cabeçalho em vez de desmontar JSON. Se alguma vez quis limites de taxa por ferramenta na periferia, é este o gancho que faltava.

Resultados de listagem que pode mesmo guardar em cache

SEP-2549

ttlMs e cacheScope em resultados de listagem e leituras de recursos. Campo pequeno, fatura grande: é a diferença entre voltar a pedir o catálogo de ferramentas em cada sessão e pedi-lo quando muda.

Autorização que valida o emissor

RFC 9207

Validação do emissor antes de trocar o código, e um afastamento do registo dinâmico de clientes a favor dos Client ID Metadata Documents como via preferencial. Pouco vistoso, e do género de coisa que fecha em silêncio toda uma classe de ataques de substituição de tokens.

3. A descoberta progressiva é uma questão de custo antes de ser de arquitetura

De tudo o que está no roteiro, este é o ponto que um fundador sente primeiro e o que mais facilmente se arruma como sendo um luxo.

O roteiro coloca a questão assim: os servidores "precisam de mais opções para guiar os clientes por conjuntos grandes de ferramentas", e os clientes deviam "conhecer as ferramentas e os recursos de um servidor à medida que precisam deles, em vez de engolir o catálogo completo à partida".

Eis porque isso é uma linha na sua fatura. Hoje, o catálogo de ferramentas entra na janela de contexto no início da sessão. Todas as ferramentas. Todas as descrições. Todos os esquemas de parâmetros. Em cada tarefa. Ligue quatro ou cinco servidores MCP de alguma dimensão e está a gastar milhares de tokens antes de o modelo ter lido a primeira frase do utilizador — e volta a pagar na tarefa seguinte, e na outra a seguir.

É a mesma falha de um AGENTS.md demasiado exaustivo, a entrar por outra porta: conteúdo carregado sem condições, precise a tarefa dele ou não. A solução é a mesma nos dois casos — tornar o carregamento condicional — e só um deles tem um grupo de trabalho a construir o mecanismo por si.

Daqui saem duas coisas. Enquanto a descoberta progressiva não existir, o número de servidores MCP que liga é uma decisão de custo em direto, não de capacidade, e o valor por omissão sensato são menos servidores com conjuntos de ferramentas mais estreitos. E quando existir, os servidores que ganham com ela são aqueles cujas ferramentas tiverem sido organizadas em algo que um cliente consiga percorrer — uma escolha de desenho que pode fazer já, na forma como agrupa e nomeia as ferramentas, antes de qualquer mecanismo sair.

O roteiro nota ainda que a descoberta progressiva tem uma "interação definida com o trabalho de cache", ou seja, que descoberta e cache por TTL estão a ser desenhadas para funcionar em conjunto em vez de colidirem. É o tipo de pormenor que decide se uma funcionalidade é utilizável no primeiro ano ou só no terceiro.

4. Identidade de agentes: a chave de API colada passou a ponto do roteiro

A terceira área prioritária é a que diz o problema em voz alta. A descrição que o próprio roteiro faz do estado atual:

Os servidores MCP existentes apoiam-se em chaves de API coladas e tokens de renovação de longa duração.

É uma descrição exata de quase todos os sistemas de agentes hoje em produção, incluindo muitos que se descreveriam como seguros. O trabalho priorizado contra isso:

O que está a ser normalizado, e o que substitui

Grupo de trabalho de identidade de agentes, em formação neste período

DPoP — Demonstrating Proof of Possession. Liga um token a uma chave que o cliente detém, de modo que um token roubado não serve por si só. Substitui: um token portador que funciona para quem o tiver.
Workload Identity Federation (SEP-1933) — um agente que se autentica como si próprio, enquanto carga de trabalho na cloud, e não com a credencial copiada de uma pessoa. Substitui: a conta de serviço cuja chave está numa variável de ambiente.
ID-JAG e a troca de tokens da RFC 8693 — uma forma normalizada de agir por um utilizador ausente e de dar a um subagente menos autoridade do que ao seu pai. Substitui: subagentes que herdam a credencial completa por não haver maneira de a estreitar.
Atestação de presença humana — em discussão, sem compromisso. Distinguir um cliente interativo de um agente sem interface, que é a pergunta que hoje todos os limitadores de taxa e sistemas antifraude adivinham.

A metade da delegação merece ênfase, por corresponder a um erro de arquitetura verdadeiro. Quando hoje um agente lança um subagente, este corre quase sempre com as credenciais do pai, porque estreitá-las exige maquinaria que ninguém construiu. Isso significa que o raio de impacto do passo menos fiável da sua cadeia é o raio de impacto da cadeia inteira. É o mecanismo, não uma hipótese — e é a mesma conclusão a que chegámos pelo outro lado em Os agentes de IA precisam de sistemas de permissões, não de melhores prompts.

Uma ressalva, a mesma que se aplica à consolidação de protocolos que tratámos na semana passada: a identidade responde a quem está a chamar. Não responde a se o que pede é boa ideia. Um agente perfeitamente autenticado que leu uma instrução maliciosa numa página web fará a sua chamada maliciosa com credenciais impecáveis. Tudo o que o guia de segurança de agentes diz sobre tratar como não fiável o conteúdo visível ao modelo sobrevive intacto a tudo isto.

5. Como ler um roteiro quando se lança daqui a oito semanas

Um roteiro não é uma data de entrega. O próprio documento o diz: "o pensamento atual e não compromissos firmes", num horizonte de seis a doze meses. Em duas das cinco áreas os grupos de trabalho ainda estão a formar-se.

Por isso a pergunta útil não é pelo que esperar. É o que isto lhe diz sobre onde devem ficar as costuras.

Tudo o que já saiu

Adotar

Núcleo sem estado, encaminhamento por cabeçalhos, cache de listagens, validação do emissor. Está na especificação 2026-07-28, não num roteiro. Adote-o, e apague os remendos que substitui.

Identidade, trabalho longo, descoberta

Fazer à mão, mas isolado

Não pode esperar por isto nem o deve tentar. Construa a versão tosca — um token por agente, uma tabela de trabalhos para tudo o que passe dos trinta segundos, uma lista de ferramentas tratada à mão — por trás de uma interface estreita o bastante para que trocá-la seja um dia e não um trimestre.

O que a especificação está a redesenhar

Não construir

A forma do resultado do tools/call está a ser refeita porque content e structuredContent produziram implementações divergentes. Não invista num tratamento engenhoso de uma forma que está na lista para mudar.

O cartão do meio é o que carrega o peso. Tudo o que está nas primeiras quatro áreas prioritárias é algo que uma equipa a lançar hoje resolve de maneira informal. O valor do roteiro para um fundador é dizer-lhe quais das suas soluções informais são temporárias por desenho — e essas são exatamente as que merecem uma interface em vez de ficarem espalhadas pelo código.

Em concreto, para uma equipa a construir um produto com agentes este trimestre: se o tratamento de credenciais, o de tarefas longas e a montagem do catálogo de ferramentas viverem cada um num só sítio com pouca superfície, adotará as normas quando chegarem ao seu SDK e será um não-acontecimento. Se estiverem espalhados pelos pontos de chamada, não as adotará, e descreverá isso como uma decisão de prioridades.

6. O que o roteiro não resolve

Três coisas que convém dizer com clareza, porque um roteiro bem escrito cria uma ligeira ilusão de cobertura.

Não torna os agentes fiáveis. Tudo aqui é transporte, identidade e descoberta. Nada toca em saber se o modelo escolheu a ferramenta certa, leu bem o resultado ou devia ter parado. Isso continua a ser um problema de avaliação e continua a ser seu.

Não encurta a sua cadeia de dependências. Um núcleo sem estado e um transporte unificado tornam mais fácil ligar mais servidores. Fácil não é grátis: cada servidor ligado é custo de contexto, um modo de falha e uma fronteira de confiança. O protocolo melhorar nas ligações não é argumento para ter mais ligações.

Não chega num calendário com que possa planear. Dois grupos de trabalho ainda se estão a formar. As tarefas continuam a ser uma extensão a caminho da "eventual inclusão no protocolo central". Planear com juízo é tratar cada ponto do roteiro como algo que talvez chegue ao seu SDK para o ano, e construir como se pudesse não chegar.

O resumo honesto

O roteiro do MCP atualizado a 22 de agosto é um documento estratégico melhor do que aquilo que a maioria das empresas escreve sobre si mesma, porque nomeia a sua própria suposição errada em linguagem simples em vez de vender a correção como inovação. O protocolo foi feito para uma pessoa com navegador, num portátil, à espera de uns segundos pela resposta de um punhado de ferramentas. As quatro coisas são hoje falsas em produção, e o roteiro é o trabalho de as desfazer.

Para um fundador, o conteúdo prático não é a lista de funcionalidades. É a confirmação de que quatro das coisas que hoje remenda — credenciais para utilizadores ausentes, trabalho que sobrevive a um pedido, catálogos grandes demais para carregar, e um transporte que se porta de maneira diferente num portátil e num cluster — são temporárias por desenho, estão nas mãos de pessoas com nome, e merecem uma interface já.

Construa a versão tosca. Mantenha a costura. Apague os remendos que já têm norma.

Fontes: Model Context Protocol — roteiro, atualizado a 2026-08-22 · A especificação 2026-07-28, blogue do MCP · SEP-2575, MCP sem estado · SEP-2549, TTL para resultados de listagem · SEP-2663, extensão de tarefas · Grupos de trabalho e de interesse

O A2A acabou de se mudar para junto do MCP. Normalizar como os agentes falam não normaliza se acertam20 de agosto de 2026

Your AI Agent Has a Security Problem: A Founder's Security Guide for 2026July 17, 2026

Context Engineering: The Skill That Makes or Breaks AI MVPs in 2026April 2026

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →