MCP publica novo roteiro com foco em HTTP e identidade de agentes

Os Core Maintainers do Model Context Protocol (MCP), o padrão aberto hospedado pela Agentic AI Foundation (AAIF) da Linux Foundation, publicaram um roteiro atualizado que define o rumo do protocolo para a próxima versão da especificação e além. Segundo reportou o site técnico japonês Publickey, o roteiro está organizado em cinco áreas prioritárias: mensageria para agentes, unificação do transporte em torno do HTTP, identidade de agentes e segurança pronta para empresas, melhoria das ferramentas básicas e uma experiência melhor para desenvolvedores de SDK. O blog oficial do MCP confirma que o roteiro foi elaborado em conjunto pelos Core Maintainers e pela comunidade de Working Groups, e que ele "define a direção do trabalho no protocolo para os próximos meses".

O MCP nasceu em novembro de 2024 como um protocolo proposto pela Anthropic para conectar seus modelos Claude a fontes de dados e ferramentas externas. Em 9 de dezembro de 2025, a Linux Foundation anunciou ter recebido a doação do protocolo e criou a Agentic AI Foundation para governar sua evolução, com Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft e OpenAI como membros platina. Segundo o anúncio da Linux Foundation, o MCP se tornou um dos projetos de código aberto de crescimento mais rápido do último ano, com mais de 97 milhões de downloads mensais de SDK e mais de 10 mil servidores ativos, integrado nativamente ao ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot e Visual Studio Code. Em julho, a extensão "Enterprise-Managed Authorization" (EMA) chegou à versão estável e o protocolo passou a conexões sem estado, uma atualização importante que facilita implantações em grande escala.

Cinco áreas prioritárias

Segundo a publicação oficial "The New MCP Roadmap", esta atualização dá continuidade ao roteiro anterior, publicado em março, que tinha quatro prioridades: evolução e escalabilidade do transporte, comunicação entre agentes, amadurecimento da governança e preparação para empresas. A maior parte do progresso dos últimos cinco meses chegou com a versão de especificação de 28 de julho de 2026 (2026-07-28). As sessões em nível de protocolo e o handshake de inicialização foram removidos, permitindo que servidores escalem horizontalmente sem manter estado (SEP-2575, SEP-2567); os clientes ganharam uma chamada `server/discover` para conhecer as capacidades de um servidor antes de se conectar; e os resultados de listas passaram a ser armazenáveis em cache (SEP-2549).

• Mensageria para agentes: construir eventos iniciados pelo servidor (webhooks e canais) para que os clientes parem de fazer polling em busca de resultados, e amadurecer a extensão Tasks (SEP-2663) até sua inclusão na especificação principal
• Unificação do transporte em torno do HTTP: estender o Streamable HTTP também para servidores locais, usando HTTP/2 sobre stdio para manter o multiplexing sem perder as garantias de um subprocesso
• Identidade de agentes e segurança pronta para empresas: finalizar o Demonstrating Proof of Possession (DPoP) e definir identidade e delegação de agentes via Workload Identity Federation (SEP-1933) e troca de tokens ID-JAG, em vez de chaves de API copiadas ou tokens de longa duração
• Melhoria das ferramentas básicas: padronizar o formato das respostas de `tools/call` e introduzir descoberta progressiva, para que um modelo não precise carregar todo o catálogo de ferramentas de um servidor antes mesmo da primeira pergunta do usuário
• Melhor experiência de desenvolvedor para SDKs: refinar a ergonomia das APIs e a precisão da documentação, já que muitos desenvolvedores — e cada vez mais os próprios agentes de IA — escrevem código de cliente ou servidor MCP diretamente a partir dos SDKs

O que isso resolve para as empresas

O modelo de autorização atual do MCP pressupõe que um humano aprove o acesso em um navegador. O blog oficial observa que uma parcela crescente dos chamadores agora são agentes rodando como cargas de trabalho na nuvem com identidade própria, agindo em nome de um usuário ausente, ou delegando autoridade mais restrita a subagentes. O trabalho de identidade busca dar aos servidores MCP uma forma padronizada de reconhecer e confiar nessas identidades de agentes, apoiada em padrões já existentes em vez de chaves de API copiadas, em coordenação com os grupos de trabalho IETF OAuth e WIMSE sobre a mecânica de troca de tokens subjacente. A unificação em torno do HTTP importa tanto quanto operacionalmente: um servidor MCP remoto construído sobre Streamable HTTP já não se distingue de qualquer outra carga de trabalho HTTP, permitindo que empresas o hospedem e escalem na mesma infraestrutura — balanceadores de carga, gateways, observabilidade — que já usam para suas APIs, em vez de construir uma tubulação sob medida para um protocolo à parte.

Sobre a priorização, o blog oficial é explícito: propostas (SEPs) que se encaixam em uma das cinco áreas prioritárias recebem revisão acelerada, enquanto as demais não são rejeitadas automaticamente, mas enfrentam prazos mais longos e uma barra de justificativa mais alta, já que a capacidade de revisão dos mantenedores é limitada e está sendo direcionada deliberadamente a essas cinco áreas.

Por que isso importa para equipes que constroem agentes

O MCP já é o conector que a maioria dos grandes produtos de IA — ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code — usa para alcançar ferramentas externas, o que torna esse roteiro muito mais do que um documento interno de engenharia: ele sinaliza para onde caminha o padrão de fato da conectividade entre agentes e ferramentas. Para empresas que conectam agentes de IA a sistemas internos, o trabalho de unificação HTTP deve reduzir o custo operacional de rodar servidores MCP em grande escala, eliminando a necessidade de infraestrutura separada para implantações baseadas em stdio ou WebSocket. O trabalho de identidade endereça um risco bem concreto que as equipes já carregam: chaves de API compartilhadas entre serviços ou que permanecem válidas depois que um funcionário muda de cargo. Uma forma padronizada de restringir e revogar as credenciais próprias de um agente, apoiada em registros de auditoria, substitui o compartilhamento informal de chaves por algo que um time de segurança pode realmente governar. Organizações que hoje autenticam suas conexões MCP com tokens de longa duração devem ver isso como um sinal precoce para planejar uma migração assim que esse trabalho de identidade e delegação for entregue.