O novo roadmap do MCP: o que significa para quem constrói sobre ele

Em 22 de agosto, os mantenedores do Model Context Protocol publicaram um roadmap atualizado cobrindo os próximos seis a doze meses de trabalho do protocolo. Ele nomeia cinco áreas prioritárias, os Core Maintainers responsáveis por cada uma e uma regra silenciosa, mas importante, sobre quais propostas são revisadas primeiro. O roadmap anterior, de março, prometeu quatro coisas e entregou a maioria na release da especificação de julho, então este ganhou o direito de ser levado a sério. Minha leitura: MCP está deliberadamente se tornando infraestrutura web comum, e a pergunta útil para quem constrói é qual parte do stack isso muda primeiro.

Principais conclusões - O roadmap estabelece cinco prioridades: agentic messaging, um único transporte HTTP-native, agent identity e enterprise security, primitives de tools mais limpas e SDKs gerados a partir da especificação. - Spec Enhancement Proposals, SEPs, dentro dessas áreas recebem revisão acelerada. Fora delas, espere fila maior e barra mais alta. - As promessas do roadmap de março chegaram em grande parte à spec 2026-07-28: core stateless, resultados de lista cacheable e Multi Round-Trip Requests. - As duas mudanças mais prováveis de tocar seu código são agent identity, DPoP e Workload Identity Federation, e progressive tool discovery para catálogos grandes. - Trate o roadmap como direção, não compromisso. Os mantenedores dizem isso explicitamente. Não pause o build esperando.

O que os mantenedores do MCP realmente anunciaram?

Primeiro os fatos. O roadmap MCP atualizado, datado de 22 de agosto de 2026, organiza o próximo ciclo da spec em cinco áreas prioritárias, cada uma com Core Maintainers nomeados e um ou mais Working Groups por trás:

1. Agentic messaging primitives: eventos iniciados pelo servidor, channels, subscriptions e webhooks, para que clients parem de fazer polling, além de uma composition review para Tasks, triggers e progress notifications compartilharem um lifecycle.

2. HTTP-native transport unification and hardening: Streamable HTTP como binding único, no futuro falado sobre stdio para servidores locais, e caching ampliado para ETags.

3. Agent identity and enterprise-ready security: finalizar DPoP, Demonstrating Proof of Possession, e definir um caminho opinionated para agent identity e delegation baseado em padrões IETF existentes.

4. Improved primitives: redesign do formato de resultado de tools/call e novo esforço de progressive discovery para que clients conheçam o catálogo de um servidor conforme necessário.

5. Improved SDK developer experience: um extension contract e um experimento para gerar diretamente da especificação um SDK Tier 1 e seus quickstarts.

Ao lado das cinco áreas existe uma regra que vai moldar o resto: SEPs dentro das prioridades recebem review acelerado, e propostas com um Working Group por trás avançam mais rápido. Nas palavras dos mantenedores, "maintainer review time is scarce. We spend it here first." O roadmap também diz claramente que reflete o pensamento atual, não commitments firmes, então itens podem atrasar ou chegar em outra forma.

O roadmap MCP publicado em 22 de agosto de 2026 define cinco áreas prioritárias para os próximos seis a doze meses: agentic messaging, transporte HTTP-native, agent identity, primitives de tool melhoradas e SDKs gerados da spec. Propostas nessas áreas recebem review acelerado; fora delas enfrentam fila maior.

Por que esse roadmap importa?

Importa porque o anterior entregou. Roadmaps de projetos open source jovens frequentemente são documentos aspiracionais que envelhecem em silêncio. Este tem track record. O roadmap de março de 2026 definiu quatro prioridades e a maior parte chegou cinco meses depois na release da especificação 2026-07-28:

A adoção dá peso ao roadmap. Em julho de 2026, os SDKs Tier 1 do protocolo viam quase meio bilhão de downloads por mês, com os SDKs TypeScript e Python cada um acima de um bilhão de downloads totais. Quando protocolo nessa escala diz para onde vai, vale ler o mapa.

Fonte: roadmap MCP de março e agosto de 2026 e anúncio da especificação 2026-07-28.

O roadmap MCP de março de 2026 prometeu transport evolution, agent communication, governance maturation e enterprise readiness. Cinco meses depois, a especificação 2026-07-28 entregou core de protocolo stateless, extension Tasks, Multi Round-Trip Requests e deprecation policy formal com janela mínima de doze meses.

O que significa se você constrói sobre MCP?

Para builders, o impacto imediato é desigual. Duas das cinco áreas provavelmente mudarão seu código dentro de um ano. As outras três mudam mais como o protocolo é governado e mantido ao seu redor. Aqui está cada área traduzida.

Agentic messaging: o fim do polling

Trabalho real de agente não cabe bem em request e response. Jobs rodam por minutos, servers terminam enquanto client não olha e hoje a única resposta do client é polling, caro e feio. O roadmap prioriza eventos iniciados pelo server: channels, subscriptions e webhooks, para que servidor diga ao client quando trabalho terminou. Composition review importa tanto quanto. Tasks, subscriptions/listen e progress notifications hoje correm risco de virar três respostas diferentes para "server ainda não terminou", e mantenedores querem lifecycle, modelo de cancelamento e error surface compartilhados. Se você constrói tools long-running, esta é a área para acompanhar no Discord.

Um transporte, falado em todo lugar

A release 2026-07-28 transformou servidor MCP remoto em workload HTTP normal. O roadmap agora quer apagar divisão entre remote e local: Streamable HTTP como binding único, falado por stdin e stdout para servidores locais, com HTTP/2 fornecendo multiplexing enquanto subprocess mantém garantias de security e lifecycle. Hoje toda feature HTTP-native precisa de segundo design específico para stdio ou não funciona localmente, e SDKs mantêm duas transport pipelines. Um modelo de transporte significa menos disso. Caching também se amplia: ETags sobre hints ttlMs e cacheScope que chegaram em julho, para resultados de tool call serem versionados em vez de refetched.

Agent identity: a mudança que morde primeiro

A authorization MCP presume uma pessoa com browser no momento do consent. Cada vez mais o caller é um agent: cloud workload com identity própria, agindo por user ausente, ou criando sub-agents que deveriam receber authority menor que parent. Honeycomb, citada no anúncio da release de julho, já atribui quase 20% das queries interativas mensais a agents. Enquanto isso, muitos servidores MCP de production ainda dependem de API keys coladas e refresh tokens long-lived, exatamente prática que este trabalho pretende aposentar. O plano é finalizar e adotar DPoP, além de caminho padrão de delegation via Workload Identity Federation, SEP-1933, grant ID-JAG por trás de Enterprise-Managed Authorization e RFC 8693 token exchange, coordenado com Working Groups OAuth e WIMSE do IETF.

O modelo de authorization do MCP foi criado para humano aprovando access em browser, mas agents estão virando callers. O roadmap prioriza DPoP e caminho padrão de delegation baseado em Workload Identity Federation e RFC 8693 token exchange, para servers reconhecerem agent identities sem API keys coladas ou tokens long-lived.

Resultados de tools e progressive discovery

Duas confusões são corrigidas aqui. A primeira é tools/call retornando content e structuredContent ao mesmo tempo, produzindo implementações divergentes porque server author não sabe qual forma client vai mostrar ao model. Esse contract será redesenhado. A segunda é escala: conecte a server com cem tools e model paga por toda surface antes de user fazer uma pergunta, e tool selection piora conforme lista cresce. A token bill não é teórica. No teste da Cloudflare de fevereiro de 2026, expor API com 2.500 endpoints como definições de MCP tools consumiu cerca de 1,17 milhão de tokens, versus cerca de 1.000 por code-calling. Progressive discovery é resposta proposta: entry point pequeno que revela mais catálogo conforme conversa estreita, ligado ao trabalho de caching acima. Já escrevi sobre quando esse overhead faz API simples ser escolha melhor; progressive discovery é tentativa do MCP de reduzir gap.

SDKs gerados da spec

O item mais silencioso pode ser o mais revelador. Hoje SDKs, reference servers e quickstarts são mantidos manualmente. O roadmap faz experimento: gerar candidate SDK Tier 1 e quickstarts diretamente da especificação, validar contra conformance test suite e publicar resultados, incluindo quais layers deveriam ser deterministic codegen e quais model-assisted. Se funcionar, bugs de clareza da spec aparecem como generation failures e SDKs deixam de divergir do documento que deveriam implementar.

O que fazer agora?

Quatro coisas, em ordem de urgência:

1. Esta semana: pare de construir trabalho novo em surfaces deprecated. Roots, Sampling, Logging e transport legacy HTTP+SSE foram deprecated na spec 2026-07-28 com janela mínima de doze meses. Ainda funcionam. Implementações novas não deveriam adotar.

2. Este mês: deixe servidor cache-friendly. List results já carregam ttlMs e cacheScope, e ETags estão vindo. Servidor que emite cache hints sensatos hoje está uma migration à frente.

3. Neste trimestre: audite como agents autenticam. Se servidor MCP que você opera confia em API key colada ou refresh token long-lived para caller unattended, esse é exatamente padrão que Agent Identity Working Group existe para substituir. Acompanhe grupo em vez de criar delegation scheme próprio. O ângulo de governance conecta ao que cobri em governar AI agents.

4. Se quer moldar protocolo: escreva SEP dentro de área prioritária. Leve primeiro ao Working Group relevante e consiga apoio. Propostas alinhadas com roadmap têm review acelerado; as de fora entram na fila.

Duas coisas para não fazer. Não pause build esperando próxima spec: a atual é base estável, e deprecation policy agora garante aviso de doze meses sobre qualquer coisa que suma. E não trate roadmap como promessa. Ele diz já na primeira seção que prioridades podem mudar e trabalho não listado ainda pode ship. Se você está mais cedo na jornada, meu walkthrough prático para primeiro servidor MCP e shortlist de servidores que vale conectar são pontos de partida práticos.

A especificação MCP 2026-07-28 deprecated Roots, Sampling, Logging e transport legacy HTTP+SSE com janela mínima de doze meses. O anúncio da release confirma que continuam funcionando durante período, mas implementações novas não deveriam adotar.

O quadro maior

Dê um passo atrás e padrão é protocolo amadurecendo em público. MCP foi doado à Agentic AI Foundation vendor-neutral sob a Linux Foundation em dezembro de 2025, com OpenAI e Block como cofundadores. Desde então ganhou contributor ladder, feature lifecycle, deprecation policy e agora declaração pública de onde atenção dos maintainers vai. Extensions framework faz trabalho silencioso, mas real: SEP-2133 permite qualquer Working Group experimentar em repository experimental-ext- antes de proposta formal, então ideias são testadas sem desestabilizar core.

O que observaria nos próximos dois trimestres é HTTP over stdio. Se servidores locais e remote realmente convergirem em um transporte, "MCP server" deixa de ser tipo especial de software e vira web service com face padrão. Esse é ponto em que protocolo desaparece na plumbing, que é o que boa infraestrutura deve fazer.

Perguntas frequentes

MCP está estável o suficiente para construir agora?

Sim, com disciplina de migração. A spec 2026-07-28 introduziu deprecation policy formal com janela mínima de doze meses, e SDKs shipam migration notes para breaking changes. Protocolo continuará mudando, mas agora avisa com um ano de antecedência quando algo de que você depende vai embora.

O que aconteceu com as MCP sessions?

Foram retired na especificação 2026-07-28. Handshake initialize e header Mcp-Session-Id sumiram, SEP-2575 e SEP-2567. Cada request agora é self-describing, carregando protocol version e client capabilities em _meta, e call opcional server/discover substitui handshake para clients que querem capabilities upfront. Qualquer request pode cair em qualquer instance atrás de load balancer round-robin.

Devo esperar próxima spec antes de construir?

Não. O roadmap descreve direção para próximos seis a doze meses, não features committed, e mantenedores dizem isso explicitamente. Spec atual é estável, cacheable e stateless. Construa nela, fique longe de surfaces deprecated e acompanhe dois Working Groups cujo output mais vai tocar você.