MCP entra na era dos agentes: o que o novo roadmap muda na arquitetura da IA
O novo roadmap do Model Context Protocol coloca mensageria assíncrona, identidade de agentes, segurança empresarial e descoberta progressiva de ferramentas no centro de sua evolução. O MCP começa a deixar de ser apenas uma interface entre modelos e ferramentas para se tornar uma camada importante da infraestrutura de sistemas agentic.
O Model Context Protocol está mudando de escala
Quando o Model Context Protocol, o MCP, começou a ganhar adoção, sua proposta parecia relativamente simples: oferecer uma forma padronizada para que aplicações baseadas em modelos de linguagem acessassem tools, resources e prompts.
Em outras palavras, em vez de cada aplicação inventar sua própria integração entre um LLM e sistemas externos, o MCP oferecia um protocolo comum.
Essa descrição continua correta.
Mas já não descreve adequadamente tudo o que o MCP está tentando se tornar.
Em 22 de agosto de 2026, os mantenedores do projeto publicaram um novo roadmap para os próximos seis a doze meses. O documento organiza o desenvolvimento do protocolo em cinco grandes prioridades:
- Agentic Messaging Primitives
- HTTP-Native Transport Unification and Hardening
- Agent Identity and Enterprise-Ready Security
- Improved Primitives
- Improved SDK Developer Experience
O mais interessante não é apenas a lista.
É o problema arquitetural que existe por trás dela.
Os sistemas de IA estão deixando de executar apenas chamadas rápidas de ferramentas e começando a operar processos que podem durar minutos ou horas, produzir eventos, delegar tarefas, aguardar informações, executar subtarefas e interagir com múltiplos serviços.
O MCP está sendo redesenhado para esse mundo.
Antes de entender o roadmap, precisamos olhar para julho de 2026
A mudança não começou agora.
Em 28 de julho de 2026, o projeto publicou uma das maiores revisões da especificação MCP desde sua criação.
A versão 2026-07-28 trouxe, entre outras mudanças:
- um núcleo stateless;
- remoção da dependência de sessões no protocolo;
- requisições Multi Round-Trip Requests — MRTR;
- informações de roteamento através de headers HTTP;
- respostas de listas que podem ser armazenadas em cache;
- endurecimento do modelo de autorização;
- um framework formal de extensões;
- uma política formal de depreciação;
- atualização dos SDKs principais.
Na prática, isso tornou os servidores MCP remotos muito mais compatíveis com a infraestrutura tradicional da Web.
Um servidor pode ser distribuído entre várias instâncias atrás de um load balancer sem depender obrigatoriamente de sticky sessions ou de um estado de sessão mantido pelo protocolo.
Método e nome da ferramenta também podem ser transportados em headers como Mcp-Method e Mcp-Name, permitindo que proxies e gateways tomem decisões de roteamento e autorização sem precisar interpretar toda a mensagem do protocolo.
Esse trabalho resolveu boa parte do problema de escalabilidade do MCP.
O novo roadmap tenta resolver o próximo problema:
como fazer agentes autônomos operarem sobre essa infraestrutura de maneira segura, eficiente e interoperável?
Do roadmap de março ao roadmap de agosto
O roadmap publicado em março de 2026 tinha quatro áreas principais:
| Março de 2026 | Agosto de 2026 |
|---|---|
| Transport Evolution and Scalability | HTTP-Native Transport Unification |
| Agent Communication | Agentic Messaging Primitives |
| Governance Maturation | Improved SDK Developer Experience |
| Enterprise Readiness | Agent Identity and Enterprise Security |
| — | Improved Primitives |
Também existiam assuntos classificados como “On the Horizon”.
Entre eles estavam:
- eventos iniciados pelo servidor;
- novos tipos de resultados;
- aprofundamento de segurança;
- autorização;
- identidade de workloads;
- evolução das extensões.
Agora alguns desses temas deixaram de ser experimentais ou secundários e passaram a ocupar o centro do roadmap.
Isso é um sinal importante de maturidade.
1. Agentic Messaging Primitives: quando request/response deixa de ser suficiente
Esse talvez seja o ponto mais importante do novo roadmap.
Grande parte das APIs tradicionais funciona assim:
Cliente → requisição → servidor
Cliente ← resposta ← servidor
É um modelo excelente para operações rápidas.
Mas um agente pode executar algo diferente:
Agente
↓
inicia tarefa
↓
busca informações
↓
executa ferramentas
↓
aguarda serviço externo
↓
solicita nova informação
↓
retoma processamento
↓
produz resultado
Essa operação talvez leve 30 segundos.
Talvez 20 minutos.
Talvez horas.
O modelo request/response puro começa a ficar inadequado.
Por isso o MCP está evoluindo conceitos como:
- Tasks;
subscriptions/listen;- notificações de progresso;
- eventos iniciados por servidores;
- channels;
- subscriptions;
- webhooks.
O objetivo é permitir que o servidor avise ao cliente quando algo aconteceu, em vez de obrigar o cliente a perguntar continuamente:
Terminou?
Terminou?
Terminou?
Terminou?
Esse polling constante é caro e pouco eficiente.
Tasks podem se tornar uma das peças fundamentais do MCP
A extensão Tasks merece atenção especial.
A SEP-2663, já em status Final como proposta de extensão, define um mecanismo pelo qual uma chamada como tools/call pode retornar não o resultado final, mas um identificador de tarefa.
O cliente passa a poder trabalhar com operações como:
tasks/get
tasks/update
tasks/cancel
Uma tarefa também possui estados como:
working
input_required
completed
cancelled
failed
Isso aproxima o MCP muito mais da realidade de sistemas distribuídos e plataformas de agentes.
Uma ferramenta pode, por exemplo, iniciar:
- treinamento de um modelo;
- processamento de um dataset;
- análise de milhares de documentos;
- geração de um relatório;
- execução de um pipeline;
- deploy de uma aplicação;
- consulta a sistemas externos.
O agente não precisa bloquear esperando o resultado.
Ele pode continuar executando outras atividades e retornar à tarefa posteriormente.
O roadmap indica que Tasks continuará amadurecendo com o objetivo eventual de entrar no protocolo principal.
2. O MCP quer unificar seu transporte em torno do HTTP
A segunda prioridade parece menos chamativa, mas é arquiteturalmente importante.
Hoje o MCP possui dois mundos bastante diferentes.
Servidores remotos utilizam HTTP.
Servidores locais frequentemente utilizam stdio.
Isso significa manter comportamentos diferentes para duas formas de transporte.
O novo roadmap propõe algo bastante interessante:
utilizar Streamable HTTP também sobre stdin/stdout.
Uma das possibilidades sendo estudadas é utilizar HTTP/2 sobre stdio.
O processo continuaria local e preservaria características desejáveis do modelo de subprocessos, mas a semântica do transporte poderia ser unificada.
A arquitetura conceitualmente se aproximaria de:
MCP
│
Streamable HTTP
┌──────┴──────┐
│ │
TCP/HTTP stdio
remoto local
Isso reduz dois problemas:
- SDKs não precisam manter pipelines completamente diferentes;
- novas funcionalidades de transporte não precisam ganhar uma implementação HTTP e outra específica para stdio.
É uma simplificação importante para o ecossistema.
Cache também passa a importar
A especificação de julho já introduziu ttlMs e cacheScope para alguns resultados.
Agora o roadmap menciona a possibilidade de incorporar também ETags.
Isso pode permitir que clientes determinem se determinada representação mudou sem precisar transferir novamente todo o conteúdo.
Para catálogos grandes de ferramentas, recursos ou metadados, isso pode produzir uma diferença considerável de eficiência.
E cache se conecta diretamente a outra mudança ainda mais importante do roadmap.
3. Progressive Discovery: talvez uma das ideias mais importantes do novo MCP
Imagine um MCP Server com:
5 tools
O problema é relativamente simples.
Agora imagine um ambiente corporativo com:
100 tools
500 tools
2.000 tools
Enviar toda essa superfície para o modelo antes de qualquer pergunta é problemático.
Primeiro existe custo de contexto.
Segundo existe custo computacional.
Terceiro — e provavelmente mais importante — existe um problema de seleção.
Quanto maior o número de ferramentas disponíveis, mais difícil fica para o modelo distinguir qual representação corresponde à intenção do usuário.
O próprio roadmap reconhece que a seleção tende a piorar à medida que o catálogo cresce.
O modelo não escolhe uma função abstrata. Ele interpreta sua representação.
Quando fornecemos uma ferramenta para um modelo, o que ele realmente observa são elementos como:
name
description
inputSchema
annotations
metadata
context
Portanto, aumentar indiscriminadamente o catálogo não significa necessariamente aumentar a capacidade do sistema.
Pode significar simplesmente aumentar o espaço de decisão.
É o equivalente a entregar um catálogo de duas mil APIs ao modelo e pedir:
“Escolha a melhor.”
A solução sendo estudada pelo MCP é chamada de Progressive Discovery.
Em vez de revelar todo o universo de ferramentas imediatamente, o servidor poderia começar oferecendo uma superfície pequena.
À medida que a intenção do usuário fica mais clara:
Catálogo geral
↓
Domínio
↓
Categoria
↓
Conjunto de ferramentas
↓
Tool específica
Essa mudança é importante porque transforma tool discovery em um problema de primeira classe dentro do protocolo.
Discovery pode virar uma camada de inteligência
Imagine a pergunta:
“Analise os gastos deste trimestre e prepare um relatório para a diretoria.”
Uma arquitetura ingênua pode apresentar ao modelo centenas de ferramentas.
Com descoberta progressiva, o fluxo poderia ser:
Intenção
│
▼
Financeiro
│
├── ERP
├── Contabilidade
└── Business Intelligence
│
▼
Query Financial Data
│
▼
Tool Call
Essa abordagem reduz:
- tokens;
- ambiguidades;
- colisões semânticas;
- erros de seleção;
- exposição desnecessária de capacidades.
Também abre espaço para sistemas mais sofisticados de roteamento e seleção de ferramentas.
4. Agent Identity: agentes precisam deixar de compartilhar credenciais humanas
Aqui encontramos talvez a mudança mais importante para a adoção corporativa do MCP.
Boa parte da autenticação atual parte de uma suposição:
existe uma pessoa presente diante de um navegador.
O fluxo normalmente envolve consentimento e OAuth.
Mas sistemas agentic apresentam situações diferentes.
Um agente pode estar:
- executando em Kubernetes;
- executando em uma VM;
- operando em background;
- executando em uma função serverless;
- trabalhando em nome de um usuário ausente;
- criando outros agentes;
- delegando apenas parte de suas permissões.
Nesse cenário, utilizar simplesmente uma API key longa ou um refresh token compartilhado é uma solução limitada e potencialmente perigosa.
O roadmap quer criar uma forma padronizada de reconhecer identidades de agentes e workloads.
O agente começa a virar uma identidade computacional
Essa mudança é conceitualmente profunda.
Em muitos sistemas atuais temos:
Usuário
│
▼
Aplicação
│
▼
API
Em sistemas agentic podemos ter:
Usuário
│
▼
Agente A
│
├── Agente B
│ └── Tool
│
└── Agente C
└── MCP Server
A pergunta deixa de ser apenas:
“Quem é o usuário?”
Passamos a precisar responder:
Quem é o agente?
Quem criou esse agente?
Em nome de quem ele está atuando?
Que autoridade foi delegada a ele?
Ele pode delegar essa autoridade?
Por quanto tempo?
Para quais recursos?
Essa é uma das fronteiras centrais da segurança de sistemas autônomos.
DPoP, Workload Identity Federation e Token Exchange
O roadmap menciona explicitamente três caminhos tecnológicos.
DPoP
Demonstrating Proof of Possession reduz alguns riscos associados a bearer tokens.
Em vez de a simples posse do token ser suficiente, o cliente demonstra possuir a chave criptográfica associada àquele token.
Isso dificulta a reutilização de credenciais roubadas.
Workload Identity Federation
A SEP-1933 propõe aproveitar identidades já emitidas por plataformas de execução.
Isso pode incluir mecanismos associados a:
- Kubernetes;
- cloud providers;
- identidades de workloads;
- infraestruturas zero-trust.
A ideia é evitar criar mais um universo isolado de credenciais MCP.
Workloads poderiam utilizar credenciais de plataforma que são então validadas ou trocadas por credenciais apropriadas para acessar MCP Servers.
Token Exchange
O roadmap também cita o RFC 8693 — OAuth 2.0 Token Exchange.
Isso permite cenários como:
Identidade do usuário
│
▼
Agente
│
▼
Token Exchange
│
▼
Token com autoridade reduzida
│
▼
Subagente
Isso é exatamente o que sistemas multiagentes precisam.
Princípio do menor privilégio aplicado aos agentes
Imagine que um agente financeiro tenha acesso a:
ler_transacoes
gerar_relatorio
aprovar_pagamento
transferir_dinheiro
Ele cria um subagente apenas para analisar despesas.
Esse subagente não deveria receber automaticamente todas as capacidades do agente pai.
A delegação ideal seria:
Agente financeiro
│
├── ler_transacoes
├── gerar_relatorio
├── aprovar_pagamento
└── transferir_dinheiro
│
│ delegação restrita
▼
Agente analítico
│
├── ler_transacoes
└── gerar_relatorio
Essa forma de autoridade reduzida será fundamental para arquiteturas agentic seguras.
Enterprise-Managed Authorization
Outra peça importante é o modelo de autorização gerenciada pela empresa.
O MCP já possui uma extensão chamada Enterprise-Managed Authorization.
Nesse modelo, o Identity Provider corporativo pode continuar sendo o centro das políticas de identidade.
O fluxo pode utilizar um Identity Assertion JWT Authorization Grant — ID-JAG, posteriormente trocado por um token apropriado para o MCP Server.
Isso permite que políticas corporativas continuem controlando o acesso mesmo quando aplicações e agentes utilizam MCP.
Essa direção aproxima o protocolo de componentes já conhecidos de empresas:
Microsoft Entra ID
Okta
Keycloak
Cloud IAM
Enterprise IdPs
Em vez de criar uma ilha de autenticação para agentes.
5. tools/call também precisa amadurecer
O MCP reconhece outro problema aparentemente pequeno, mas importante.
Uma resposta de tools/call pode utilizar diferentes representações, incluindo conteúdo estruturado e não estruturado.
Isso gerou diferenças de interpretação entre implementações.
O roadmap pretende revisar o contrato de resultados para produzir uma semântica mais previsível entre clientes e servidores.
É um passo importante.
Em sistemas distribuídos, ambiguidades de representação acabam se tornando ambiguidades de comportamento.
Quanto mais agentes e plataformas interoperam, mais caro isso fica.
Primitive Annotations também serão reavaliadas
O MCP possui annotations que podem declarar informações como audiência e prioridade.
Entretanto, o roadmap reconhece que a adoção dessas annotations ainda é limitada.
A intenção agora é descobrir se:
- elas precisam ser melhor definidas;
- precisam ser mais utilizadas;
- precisam ser reformuladas;
- ou talvez devam ser depreciadas.
Esse comportamento também mostra uma mudança positiva na governança do projeto.
Nem toda funcionalidade precisa continuar existindo simplesmente porque foi criada.
6. O SDK pode começar a ser derivado da própria especificação
Outra iniciativa interessante aparece na área de Developer Experience.
Hoje:
Specification
↓
desenvolvedores interpretam
↓
SDK TypeScript
SDK Python
SDK Go
SDK C#
...
Isso cria uma possibilidade natural de divergência.
O roadmap propõe experimentar algo mais próximo de:
Specification
│
▼
Conformance Suite
│
┌───────┼────────┐
▼ ▼ ▼
SDK examples quickstarts
O projeto pretende experimentar a geração de um candidato a SDK Tier 1 e exemplos a partir da própria especificação, validando o resultado contra a suíte de conformidade.
Curiosamente, o roadmap menciona que partes desse processo poderão utilizar geração determinística e outras poderão ser model-assisted.
Ou seja:
o protocolo utilizado por agentes poderá usar agentes para ajudar a construir suas próprias implementações.
A especificação começa a se tornar executável
Esse movimento é relevante além do MCP.
Documentações de protocolos tradicionais frequentemente dependem da interpretação humana.
Uma evolução possível é transformar cada vez mais:
documentação normativa
em:
documentação
+
schema
+
testes de conformidade
+
artefatos gerados
Quanto menor a distância entre especificação e implementação, menor a probabilidade de incompatibilidades.
O que realmente mudou na visão do MCP?
Minha leitura do novo roadmap é que existem quatro mudanças estratégicas.
1. De Tool Protocol para Agentic Infrastructure
O MCP continua sendo um protocolo de contexto e capacidades.
Mas Tasks, eventos, subscriptions, progress notifications e identidade de agentes começam a formar uma infraestrutura muito mais apropriada para execuções agentic de longa duração.
2. Tool Selection virou problema de arquitetura
Progressive Discovery reconhece algo fundamental:
disponibilidade de ferramentas e capacidade de selecionar corretamente uma ferramenta são problemas diferentes.
Ter mais tools não significa ter um sistema melhor.
Uma arquitetura madura precisará controlar:
Discovery
↓
Filtering
↓
Ranking
↓
Selection
↓
Authorization
↓
Execution
Não apenas tools/list → tools/call.
3. Identidade de agentes virou infraestrutura básica
Autenticar apenas usuários humanos não será suficiente.
Sistemas agentic precisarão trabalhar com:
human identity
workload identity
agent identity
delegated identity
E provavelmente construir relações entre essas identidades.
Isso aproxima Agentic AI de problemas tradicionais de:
- IAM;
- Zero Trust;
- PKI;
- OAuth;
- workload identity;
- policy enforcement.
4. O MCP está sendo preparado para ambientes corporativos reais
A especificação de julho resolveu diversos problemas de escalabilidade.
O roadmap de agosto passa a atacar problemas de:
- identidade;
- delegação;
- segurança;
- descoberta;
- cache;
- contratos;
- operações assíncronas;
- conformidade entre SDKs.
Esses são exatamente os problemas que aparecem quando uma tecnologia sai do laboratório e começa a entrar em produção.
MCP vai substituir protocolos Agent-to-Agent?
Não.
Pelo menos não é isso que o roadmap afirma.
Esse ponto é importante.
Adicionar Tasks, eventos e mensageria assíncrona ao MCP torna o protocolo mais adequado a sistemas agentic.
Mas isso não significa automaticamente transformá-lo em um protocolo universal de negociação entre agentes.
Ainda existem problemas diferentes:
Agent
│
├── precisa acessar uma ferramenta
│ → MCP
│
├── precisa acessar contexto
│ → MCP
│
└── precisa colaborar com outro agente
→ protocolo/arquitetura Agent-to-Agent
Na prática, esses mecanismos podem ser complementares.
Arquiteturas futuras provavelmente utilizarão várias camadas de interoperabilidade em conjunto.
Uma possível arquitetura de sistemas agentic
Podemos imaginar algo como:
┌─────────────────┐
│ Usuário │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Agent Host │
└────────┬────────┘
│
┌───────────┴───────────┐
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Agent A │ │ Agent B │
└──────┬──────┘ └──────┬──────┘
│ │
Agent Messaging Agent Messaging
│ │
└──────────┬────────────┘
│
▼
┌─────────────────┐
│ MCP Discovery │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Authorization │
│ + Agent ID │
└────────┬────────┘
│
┌──────────┼──────────┐
▼ ▼ ▼
Tool Resource Task
Nessa arquitetura, descobrir uma ferramenta, ter permissão para utilizá-la e executá-la são operações diferentes.
Essa separação será cada vez mais importante.
Um detalhe importante: roadmap não significa especificação pronta
O próprio projeto deixa isso explícito.
O roadmap apresenta uma visão para aproximadamente seis a doze meses, e não uma lista de funcionalidades garantidas.
Itens podem:
- mudar;
- ser adiados;
- ganhar outro design;
- permanecer como extensions;
- ou não entrar imediatamente na especificação principal.
Portanto, não seria correto afirmar hoje que o MCP já possui, de maneira padronizada e definitiva, toda essa arquitetura de identidade, descoberta progressiva ou HTTP-over-stdio.
Esses são os problemas que os mantenedores decidiram priorizar.
E essa distinção é importante.
Para quem desenvolve MCP hoje, o que acompanhar?
Se eu estivesse construindo uma arquitetura baseada em MCP em agosto de 2026, acompanharia principalmente sete áreas:
1. Tasks
Especialmente workloads demorados e assíncronos.
2. Triggers & Events
Porque polling não escala bem para sistemas realmente orientados a eventos.
3. Progressive Discovery
Provavelmente será fundamental para MCP Servers com grandes catálogos de tools.
4. Agent Identity
Talvez seja a principal mudança para ambientes enterprise.
5. DPoP e Workload Identity Federation
Fundamentais para diminuir a dependência de tokens long-lived.
6. Extension Contract
A arquitetura de extensões será cada vez mais importante para evitar inflar o core do protocolo.
7. Conformance
À medida que diferentes clientes e servidores MCP aparecem, interoperabilidade real depende de comportamento consistente — não apenas de todos utilizarem o mesmo nome de protocolo.
E existe uma oportunidade de pesquisa aqui
Talvez a consequência mais interessante do roadmap não esteja em nenhuma feature individual.
O MCP começa a expor problemas ainda não completamente resolvidos na engenharia de sistemas agentic:
Como selecionar capacidades?
Agent → Discovery → Ranking → Tool
Como provar identidade?
Agent → Identity → Authentication
Como limitar autoridade?
Agent → Delegation → Scoped Token
Como observar execução?
Task → Events → Telemetry → Audit
Como coordenar agentes?
Agent A ↔ Agent B ↔ Services
Como verificar interoperabilidade?
Specification
↓
Conformance
↓
Runtime behavior
Essas questões vão além de conectar um chatbot a uma API.
Elas fazem parte da construção da infraestrutura de sistemas autônomos distribuídos.
O MCP está virando o TCP/IP dos agentes?
Ainda é cedo demais para fazer essa comparação.
O ecossistema de Agentic AI continua extremamente dinâmico e existem problemas que o MCP deliberadamente não tenta resolver sozinho.
Mas uma coisa ficou mais clara com o roadmap de agosto de 2026:
o MCP já não está sendo projetado apenas para conectar um modelo a uma ferramenta.
A arquitetura agora precisa lidar com agentes executando por longos períodos, servidores emitindo eventos, descoberta de grandes catálogos, workloads autenticados, autoridade delegada, infraestrutura HTTP distribuída e implementações verificadas por testes de conformidade.
É uma mudança significativa.
O MCP nasceu solucionando um problema de integração.
Agora começa a enfrentar um problema muito maior:
como criar uma infraestrutura interoperável para agentes de IA operarem no mundo real.
E talvez essa seja a evolução mais importante do protocolo até agora.
Referências
- Model Context Protocol — The New MCP Roadmap, 22 de agosto de 2026.
- Model Context Protocol — Roadmap, atualizado em 22 de agosto de 2026.
- Model Context Protocol — The 2026-07-28 Specification.
- Model Context Protocol — The 2026 MCP Roadmap, março de 2026.
- Model Context Protocol — SEP-2663: Tasks Extension.
- Model Context Protocol — SEP-1933: Workload Identity Federation.
- Model Context Protocol — Enterprise-Managed Authorization.
