MCP Anuncia Novo Roadmap — e o Hermes Já Está na Nova Especificação

No mês passado você passou uma tarde conectando algumas ferramentas internas ao MCP (Model Context Protocol, o padrão de facto para conectar aplicações de IA a sistemas e dados externos). Servidores configurados um a um, permissões ajustadas, tudo funcionando. E nesta semana você vê a notícia: o MCP anunciou um novo roadmap — “sessões de protocolo removidas”, “requisições iniciadas pelo servidor substituídas”. Seu primeiro pensamento provavelmente é: lá vamos nós de novo, outra migração? Respire. Este artigo detalha o que o roadmap oficial publicado em 22 de agosto realmente diz, quais mudanças já chegaram com a especificação 2026-07-28 e por que os usuários do Hermes já estão no novo trem.

O que o MCP anunciou: um roadmap de cinco prioridades

Em 22 de agosto, os dois mantenedores principais do MCP — David Soria Parra e Den Delimarsky — publicaram o post oficial The New MCP Roadmap, com a atualização correspondente na página do roadmap. É a continuação formal do roadmap de março (evolução de transporte, comunicação de agentes, maturação de governança, prontidão empresarial): a maior parte do trabalho dos últimos cinco meses já chegou na especificação 2026-07-28, e o novo roadmap concentra o que vem em cinco áreas prioritárias:

  1. Primitivas de mensageria agêntica: cargas de trabalho modernas não cabem mais no padrão requisição-resposta. O roadmap quer trazer Tasks (operações assíncronas de longa duração) para o corpo da especificação, além de eventos iniciados pelo servidor (webhooks e canais, para que clientes não fiquem sondando resultados), subscriptions/listen e notificações de progresso.
  2. Unificação e endurecimento do transporte HTTP nativo: desde 2026-07-28, um servidor MCP remoto é “como qualquer carga HTTP” — seus load balancers, serverless com scale-to-zero e health checks se aplicam. Próximo passo: unificar servidores locais em Streamable HTTP sobre stdio.
  3. Identidade de agentes e segurança empresarial: a autorização MCP hoje assume uma pessoa aprovando no navegador, mas cada vez mais chamadores são workloads na nuvem sem humano presente. O roadmap mira DPoP (RFC 9449 Proof of Possession), Workload Identity Federation, troca padrão de tokens, com participação contínua nos grupos de trabalho IETF OAuth e WIMSE.
  4. Primitivas melhoradas: respostas de tools/call devem carregar um contrato claro em vez de múltiplas formas; e para o modelo não pagar por um catálogo de cem ferramentas antes que o usuário faça uma única pergunta, um esforço de descoberta progressiva deixa o servidor oferecer uma entrada pequena e revelar mais conforme a conversa afunila.
  5. Melhor experiência de desenvolvimento nos SDKs: ergonomia e conformidade em todos os SDKs oficiais.

Um efeito prático: SEPs dentro dessas áreas recebem revisão acelerada. Se você está pensando em uma proposta, este é o mapa para se posicionar.

O que já chegou com a especificação 2026-07-28: quatro grandes mudanças

O roadmap diz que “a maior parte das mudanças chegou com o release 2026-07-28”. O que exatamente, para um desenvolvedor trabalhando no dia a dia?

1. O protocolo ficou sem estado. Com SEP-2575 (Stateless MCP) e SEP-2567 (Sessionless MCP), a sessão no nível de protocolo e o handshake de inicialização desapareceram. Um servidor MCP remoto agora é só um serviço HTTP: balanceie sem sticky sessions, escale para zero se quiser. Se seu servidor precisa de estado entre chamadas, crie um handle explícito a partir de uma ferramenta e faça o modelo passá-lo como argumento — mais transparente que sessões ocultas no transporte.

2. MRTR substituiu requisições iniciadas pelo servidor. Na especificação antiga, servidores podiam chamar de volta o cliente (por exemplo, para confirmar um parâmetro) — desconfortável em deploys sem estado e atrás de firewalls corporativos. O padrão Multi Round-Trip Requests (SEP-2322) funciona assim: o servidor retorna resultType: "input_required" junto com as requisições que precisa ver respondidas, e o cliente tenta novamente a chamada original com as respostas anexadas em inputResponses. Elicitation, sampling e roots migraram para esse modelo.

3. Descoberta e cache. Um cliente pode chamar server/discover para conhecer versões e capacidades suportadas antes de conectar; resultados de listas carregam dicas de cache e ordem determinística (SEP-2549), então clientes podem armazenar catálogos de ferramentas e os caches de prompt a montante ficam estáveis entre reconexões.

4. Roteamento por cabeçalhos e endurecimento de autorização. Nomes de método e ferramenta viajam nos cabeçalhos HTTP Mcp-Method e Mcp-Name, então gateways podem rotear e autorizar só pelos cabeçalhos; a autorização ganhou validação de issuer, credenciais de cliente vinculadas ao issuer e Client ID Metadata Documents (CIMD), com Enterprise-Managed Authorization virando extensão estável. A AWS já colocou Tasks no Bedrock AgentCore, e o Agents SDK da Cloudflare suporta a especificação desde o primeiro dia — isso é infraestrutura de produção, não um experimento.

Por que o Hermes já está no novo trem

“Já a bordo” não é discurso de marketing — dá para verificar no código. O Hermes traz mcp 2.0.0, cujas notas de release afirmam que ele implementa a revisão 2026-07-28. A nova especificação não é algo que o Hermes está perseguindo; é contra o que as execuções diárias já trabalham. Característica por característica, em tools/mcp_tool.py:

  • MRTR: o código trata explicitamente resultType: "input_required", reconhecendo servidores modernos com o novo padrão
  • server/discover: em modo sem estado, o Hermes sonda server/discover primeiro, com nova tentativa legacy para servidores de SDK antigo — as duas gerações conectam
  • Elicitation: um handler de elicitation/create roteia solicitações em modo formulário pelo fluxo de aprovação existente do Hermes (aprove direto do Feishu/Telegram/Slack)
  • Transportes: stdio, HTTP/StreamableHTTP e SSE, todos cobertos
  • OAuth: gerenciamento completo de cliente OAuth, emparelhado com a skill de remote gateway
  • Direção reversa: hermes mcp serve transforma o Hermes em um servidor MCP, então qualquer cliente MCP — Claude Code, Cursor, Codex — pode se conectar a conversas, enviar mensagens e aprovar solicitações

Some o hot reload /reload-mcp, um watchdog para stdio e verificações de segurança MCP: a história MCP do Hermes é uma implementação completa da nova especificação, não um mínimo “suportamos o protocolo”.

Configurando MCP no Hermes

Se você ainda não conectou um servidor MCP, adicione um bloco mcp_servers em ~/.hermes/config.yaml — stdio e remoto funcionam:

mcp_servers:
  filesystem:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/data"]
  my-remote-server:
    url: "https://mcp.example.com/mcp"
    headers:
      Authorization: "Bearer your-token"
  • command + args: servidor stdio local (iniciado como subprocesso, com watchdog para reiniciar)
  • url: servidor remoto Streamable HTTP / SSE, cabeçalhos personalizados suportados
  • Após editar, execute /reload-mcp para recarregar a quente, ou reinicie o Hermes; hermes mcp serve expõe o Hermes na direção reversa

Para a referência completa de campos (escolha de transporte, OAuth, timeouts), veja a referência de configuração MCP; para pegadinhas do dia a dia e truques de variáveis de contexto, nosso guia de config MCP e variáveis de contexto é um bom ponto de partida.

O que os próximos passos do roadmap significam para usuários do Hermes

Várias direções do roadmap se mapeiam diretamente no uso do Hermes:

  • Tasks entrando na especificação + webhooks: tarefas MCP viram uma primitiva padrão. A maquinaria de cron e tarefas em segundo plano do Hermes é madura — uma via bidirecional natural quando as Tasks MCP chegarem, deixando outros agentes invocarem seus jobs agendados.
  • DPoP e identidade de agentes: agentes na nuvem ganham autorização MCP sem humano no circuito. Um Hermes 24/7 em um VPS é exatamente essa forma — quando a identidade de “agente agindo por um usuário” amadurecer, agentes de longa vida como o Hermes serão os primeiros beneficiados.
  • Descoberta progressiva de ferramentas: chega de pagar por um catálogo gigante antecipadamente. O Hermes já faz corte de toolsets e otimização de schemas; essa direção melhora servidores com grandes superfícies de ferramentas.

Resumo

O novo roadmap do MCP traz muita coisa, mas se resume a três frases: o protocolo agora é sem estado e nativo HTTP; o próximo semestre foca em primitivas de mensageria agêntica, identidade de agentes e experiência de desenvolvimento; SEPs são priorizados contra essas cinco áreas. Para usuários do Hermes, a parte reconfortante é que a nova especificação não está no “futuro” — seu Hermes já roda com ela diariamente. Para os detalhes no nível de protocolo, leia o post oficial do roadmap e o anúncio da especificação 2026-07-28; para ver o que mais o Hermes pode fazer com MCP, esta demonstração SEO-MCP é um bom lugar para começar.