O time do Model Context Protocol publicou em 22 de agosto o roadmap das próximas versões da especificação. São cinco frentes, e duas delas mexem com quem já tem servidor MCP rodando em produção: identidade de agente e descoberta gradual de ferramentas.
O documento avisa o próprio status logo no começo. Trata-se de um horizonte de seis a doze meses descrito como
current thinking rather than firm commitments. (Model Context Protocol)
Roadmap do MCP
- Mexe em produção
Identidade de agente
no lugar de chave de API colada e token de vida longa
- Mexe em produção
Descoberta gradual de ferramentas
revela o catálogo conforme a conversa estreita
Primitivas de mensagem agêntica
Tasks, assinaturas e notificação de progresso
Transporte unificado em HTTP
inclui Streamable HTTP sobre stdio para servidor local
Ergonomia dos SDKs
conformidade à especificação e documentação melhor
Fonte · Model Context Protocol
Chave colada no arquivo tem prazo
Hoje a maioria das integrações MCP vive de chave de API colada em configuração e token de vida longa. O roadmap propõe substituir isso por identidade de agente construída sobre padrões que já existem no ecossistema OAuth: DPoP, Workload Identity Federation, Identity Assertion JWT Authorization Grant e a troca de tokens da RFC 8693.
DPoP não é invenção do MCP, é padrão IETF publicado. O trabalho do protocolo, como o próprio texto coloca, é fechar como usá-lo e empurrar adoção. Na mesma linha, o Dynamic Client Registration foi formalmente depreciado em favor do CIMD, e segue funcionando por compatibilidade até uma versão futura.
Autenticação
Chave de API colada em configuração e token de vida longa
Identidade de agente
- DPoP
- Workload Identity Federation
- Identity Assertion JWT Authorization Grant
- Troca de tokens da RFC 8693
Registro de cliente
Dynamic Client Registration
segue funcionando por compatibilidade até uma versão futura
CIMD
Fonte · Model Context Protocol
Catálogo grande de ferramenta virou problema de protocolo
A segunda frente prática é descoberta gradual. Mandar o esquema completo de todas as ferramentas antes do usuário perguntar qualquer coisa gasta contexto e piora a escolha do modelo. A proposta é revelar mais do catálogo conforme a conversa vai estreitando. Quem mantém servidor com dezenas ou centenas de ferramentas é o público direto disso.
As outras três prioridades: primitivas de mensagem agêntica, com Tasks, assinaturas e notificação de progresso indo além de requisição e resposta; unificação do transporte em HTTP, incluindo Streamable HTTP sobre stdio para servidor local; e ergonomia dos SDKs, com conformidade à especificação e documentação melhor.
O que já entrou na versão 2026-07-28
O roadmap se apoia na especificação lançada em 28 de julho, que reescreveu o núcleo do protocolo para ser sem estado. Sessões de nível de protocolo foram removidas, o que permite escalar horizontalmente. Requisições iniciadas pelo servidor deram lugar ao padrão Multi Round-Trip Requests. Resultados de listagem passaram a ser cacheáveis. Tasks saiu do núcleo experimental e virou extensão oficial.
28 jul 2026
Especificação 2026-07-28
- Núcleo sem estado; sessões removidas
- Multi Round-Trip Requests
- Listagem cacheável
- Tasks vira extensão oficial
22 ago 2026
Roadmap publicado
cinco frentes
6 a 12 meses
Horizonte do roadmap
current thinking, sem compromisso firme
Fonte · Model Context Protocol
A API Evangelist leu o conjunto como um roadmap de API tradicional vestido de protocolo de agente, com as mesmas questões de autenticação, versionamento e descoberta que o setor discute há uma década.
O que muda pra quem cria
Se você mantém servidor MCP próprio, o item urgente é auditar onde há token de vida longa em arquivo de configuração, porque essa é a prática que o roadmap quer aposentar. Servidor com catálogo grande de ferramenta vale ser agrupado agora por domínio, antecipando a descoberta gradual. Quem depende de Dynamic Client Registration deve planejar a migração para CIMD enquanto a compatibilidade ainda existe. E, para automação local, o caminho apontado é HTTP, não stdio puro.
