Novo Roadmap do MCP

Artigo original ↗ Discussão no Hacker News ↗

O roteiro atualizado do Model Context Protocol (MCP) da Anthropic está gerando reações mistas entre desenvolvedores, que recebem bem a mudança para servidores sem estado e baseados em HTTP e uma melhor autorização de agentes, mas criticam a especificação como excessivamente engenheirada e fragmentada na prática. Muitos argumentam que padrões existentes como REST + OpenAPI (ou “modo de código” com acesso HTTP direto) costumam ser mais simples e performáticos, especialmente para cargas não interativas, enquanto o valor do MCP está principalmente na descoberta padronizada de ferramentas, permissões granulares e fluxos de autenticação amigáveis para empresas. Há amplo consenso de que tokens de longa duração e aprovações manuais no navegador não escalam para agentes autônomos, mas menos consenso sobre se o MCP é a camada de abstração certa ou apenas mais um protocolo complexo surfando o ciclo de hype de IA.

Modo de código vs MCP

  • Vários comentaristas estão migrando de configurações baseadas em MCP para “modo de código” (por exemplo, a abordagem da Cloudflare), citando melhor desempenho em runtime, orquestração mais flexível de chamadas complexas de ferramentas e menos dores de cabeça com protocolo.
  • Uma pessoa pede benchmarks quantitativos comparando MCP com modo de código; nenhum dado é fornecido no thread, então o impacto relativo no desempenho permanece अस्पícuo.

Autenticação, Identidade e Segurança

  • O foco do roadmap em DPoP, Workload Identity Federation e padrões baseados em OAuth gera debate.
  • Críticos veem isso como engenharia excessiva e argumentam que tokens de longa duração armazenados em gerenciadores de segredos (por exemplo, 1Password) são mais simples.
  • Outros respondem que credenciais de longa duração, especialmente nas mãos de agentes, são inaceitáveis para muitas organizações; protocolos complexos são vistos como necessários para revogação, delegação e conformidade.
  • Autenticação de agentes não interativa, gerenciada pela empresa, é um objetivo importante; aprovações manuais no navegador são vistas como um gargalo de escala.
  • Permissões granulares, no estilo de papéis, para “subentidades” (agentes especializados) são vistas como necessárias, mas desafiadoras para a UX.

Projeto do Protocolo, Transports e Estado

  • Muitos celebram a mudança para “MCP sobre HTTP” e tratar o MCP como qualquer outra carga de trabalho HTTP; o protocolo v1 feito sob medida é amplamente criticado por ser fragmentado e confuso.
  • Há confusão sobre o futuro do stdio; o melhor palpite do thread é HTTP sobre stdio, mas isso é descrito como अस्पícito.
  • Alguns não gostam de HTTP como a camada universal de IPC e preferem um protocolo central agnóstico ao transporte; outros observam que as opções de gRPC parecem pesadas.
  • O design stateful do v1 é chamado de desfavorável para implantação e difícil de testar; a mudança em direção a statelessness é elogiada.

MCP vs REST, Skills e OpenAPI

  • Vários comentaristas argumentam que uma API REST bem documentada mais uma descrição em skills/markdown ou uma especificação OpenAPI já funciona bem para agentes.
  • O principal valor agregado do MCP é descrito como:
    • Descoberta centralizada e automática de ferramentas e atualizações.
    • Forte alinhamento entre a API e as definições de ferramentas.
    • Autorização granular, por ferramenta, e facilitação do bloqueio de capacidades.
  • Outros contestam que as empresas já gerenciam milhares de endpoints HTTP e que o MCP adiciona churn e possíveis mudanças quebráveis sem um retorno claro.

Complexidade, Adoção e Uso no Mundo Real

  • Alguns veem o MCP como “passando do ponto” ao tentar absorver demais de HTTP e auth; planejam ficar com uso mínimo no estilo JSON-RPC.
  • Há frustração de que o rollout inicial do MCP envolveu vários padrões parcialmente sobrepostos, designs carregados de contexto e suporte inconsistente de clientes, queimando a confiança.
  • Ainda assim, alguns veem o MCP como promissor para casos de uso mais restritos e interativos (por exemplo, encapsular APIs privilegiadas com segurança, ações privilegiadas via elicitations e reduzir catálogos de ferramentas para diminuir o inchaço de contexto).