MCP publica novo roteiro centrado em HTTP e identidade de agentes

Os Core Maintainers do Model Context Protocol (MCP), o padrão aberto acolhido pela Agentic AI Foundation (AAIF) da Linux Foundation, publicaram um roteiro atualizado que fixa o rumo do protocolo para a próxima versão da especificação e para além dela. Segundo relatou o site tecnológico japonês Publickey, o roteiro organiza-se em cinco áreas prioritárias: mensagens destinadas a agentes, unificação do transporte em torno do HTTP, identidade de agentes e segurança pronta para empresas, melhoria das ferramentas de base e uma melhor experiência para os programadores dos SDK. O blogue oficial do MCP confirma que o roteiro foi elaborado em conjunto pelos Core Maintainers e pela comunidade de Working Groups, e que "fixa a direção do trabalho sobre o protocolo para os próximos meses".

O MCP nasceu em novembro de 2024 como um protocolo proposto pela Anthropic para ligar os seus modelos Claude a fontes de dados e ferramentas externas. A 9 de dezembro de 2025, a Linux Foundation anunciou ter recebido a doação do protocolo e criou a Agentic AI Foundation para governar a sua evolução, com a Amazon Web Services, a Anthropic, a Block, a Bloomberg, a Cloudflare, a Google, a Microsoft e a OpenAI como membros platina. Segundo o anúncio da Linux Foundation, o MCP tornou-se um dos projetos de código aberto de crescimento mais rápido do último ano, com mais de 97 milhões de descargas mensais de SDK e mais de 10 mil servidores ativos, integrado de forma nativa no ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot e Visual Studio Code. Em julho, a extensão "Enterprise-Managed Authorization" (EMA) atingiu a versão estável e o protocolo passou a ligações sem estado, uma atualização importante que facilita implementaçõ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 governação e preparação para as 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 ao nível do protocolo e o handshake de inicialização foram removidos, permitindo que os 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 ligarem; e os resultados de listas passaram a poder ser colocados em cache (SEP-2549).

• Mensagens para agentes: construir eventos iniciados pelo servidor (webhooks e canais) para que os clientes deixem de sondar 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: alargar o Streamable HTTP também aos 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 a identidade e a delegação de agentes através da Workload Identity Federation (SEP-1933) e da troca de tokens ID-JAG, em vez de chaves de API coladas ou tokens de longa duração
• Melhoria das ferramentas de base: padronizar o formato das respostas de `tools/call` e introduzir a descoberta progressiva, para que um modelo não tenha de carregar todo o catálogo de ferramentas de um servidor antes sequer da primeira pergunta do utilizador
• Melhor experiência para os programadores de SDK: aperfeiçoar a ergonomia das APIs e a exatidão da documentação, uma vez que muitos programadores — e cada vez mais os próprios agentes de IA — escrevem código de cliente ou servidor MCP diretamente a partir dos SDK

O que isto resolve para as empresas

O atual modelo de autorização do MCP pressupõe que um humano aprova o acesso num navegador. O blogue oficial nota que uma parte crescente dos chamadores são agora agentes a correr como cargas de trabalho na nuvem com identidade própria, a agir em nome de um utilizador ausente, ou a delegar autoridade mais restrita em subagentes. O trabalho sobre identidade procura dar aos servidores MCP uma forma padronizada de reconhecer e confiar nessas identidades de agentes, apoiada em normas já existentes em vez de chaves de API coladas, 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 conta tanto operacionalmente: um servidor MCP remoto construído sobre Streamable HTTP já não se distingue de qualquer outra carga de trabalho HTTP, o que permite às empresas alojá-lo e escalá-lo na mesma infraestrutura — balanceadores de carga, gateways, observabilidade — que já usam para as suas APIs, em vez de construírem canalização à medida para um protocolo à parte.

Quanto à priorização, o blogue oficial é explícito: as propostas (SEPs) que se enquadram numa das cinco áreas prioritárias recebem revisão acelerada, enquanto as restantes não são automaticamente rejeitadas, mas enfrentam prazos mais longos e uma exigência de justificação mais elevada, uma vez que a capacidade de revisão dos mantenedores é limitada e está a ser deliberadamente concentrada nestas cinco áreas.

Porque importa às equipas 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 este roteiro muito mais do que um documento interno de engenharia: assinala para onde caminha o padrão de facto da conectividade entre agentes e ferramentas. Para as empresas que ligam agentes de IA a sistemas internos, o trabalho de unificação HTTP deverá reduzir o custo operacional de correr servidores MCP em grande escala, eliminando a necessidade de infraestrutura separada para implementações baseadas em stdio ou WebSocket. O trabalho sobre identidade responde a um risco muito concreto que as equipas já carregam: chaves de API partilhadas entre serviços ou que permanecem válidas depois de um colaborador mudar de função. Uma forma padronizada de limitar e revogar as credenciais próprias de um agente, apoiada em registos de auditoria, substitui a partilha informal de chaves por algo que uma equipa de segurança pode efetivamente governar. As organizações que hoje autenticam as suas ligações MCP com tokens de longa duração devem encarar isto como um sinal precoce para planear uma migração assim que este trabalho de identidade e delegação for entregue.