Nueva hoja de ruta de MCP

Artículo original ↗ Discusión en Hacker News ↗

La hoja de ruta actualizada de Anthropic para el Model Context Protocol (MCP) está generando reacciones mixtas entre desarrolladores, que celebran los avances hacia servidores sin estado y basados en HTTP, así como una mejor autorización para agentes, pero critican la especificación por estar sobredimensionada y fragmentada en la práctica. Muchos argumentan que patrones existentes como REST + OpenAPI (o el “modo código” con acceso HTTP directo) suelen ser más simples y más eficientes, especialmente para cargas no interactivas, mientras que el valor de MCP reside principalmente en el descubrimiento estandarizado de herramientas, permisos de grano fino y flujos de autenticación aptos para empresas. Existe un amplio consenso en que los tokens de larga duración y las aprobaciones manuales en el navegador no escalan para agentes autónomos, pero menos consenso sobre si MCP es la capa de abstracción adecuada o simplemente otro protocolo complejo persiguiendo el ciclo de entusiasmo de la IA.

Modo código vs MCP

  • Varios comentaristas están pasando de configuraciones basadas en MCP a “modo código” (por ejemplo, el enfoque de Cloudflare), citando mejor rendimiento en tiempo de ejecución, una orquestación más flexible de llamadas complejas a herramientas y menos problemas de protocolo.
  • Una persona pide puntos de referencia cuantitativos que comparen MCP con el modo código; no se proporcionan datos en el hilo, así que el impacto relativo en el rendimiento sigue sin estar claro.

Autenticación, identidad y seguridad

  • El enfoque de la hoja de ruta en DPoP, Workload Identity Federation y estándares basados en OAuth genera debate.
  • Los críticos ven esto como sobreingeniería y sostienen que los tokens de larga duración almacenados en gestores de secretos (por ejemplo, 1Password) son más simples.
  • Otros responden que las credenciales de larga duración, especialmente en manos de agentes, son inaceptables para muchas organizaciones; los protocolos complejos se consideran necesarios para la revocación, la delegación y el cumplimiento.
  • La autenticación de agentes no interactiva y gestionada por la empresa es un objetivo importante; las aprobaciones manuales en el navegador se ven como un cuello de botella para escalar.
  • Los permisos de grano fino, similares a roles, para “sub-entidades” (agentes especializados) se consideran necesarios pero difíciles desde el punto de vista de la UX.

Diseño del protocolo, transportes y estado

  • Muchos celebran el paso a “MCP sobre HTTP” y tratar MCP como cualquier otra carga de trabajo HTTP; el protocolo v1 a medida es ampliamente criticado por estar fragmentado y ser confuso.
  • Hay confusión sobre el futuro de stdio; la mejor suposición del hilo es HTTP sobre stdio, pero esto se describe como poco claro.
  • A algunos no les gusta HTTP como capa universal de IPC y prefieren un protocolo central agnóstico al transporte; otros señalan que las opciones de gRPC parecen pesadas.
  • El diseño con estado de v1 se califica de poco amigable para el despliegue y difícil de probar; el movimiento hacia la ausencia de estado es elogiado.

MCP vs REST, Skills y OpenAPI

  • Varios comentaristas sostienen que una API REST bien documentada junto con una descripción de skills/Markdown o una especificación OpenAPI ya funciona bien para agentes.
  • El principal valor añadido de MCP se describe como:
    • Descubrimiento centralizado y automático de herramientas, con actualizaciones.
    • Alineación estrecha entre la API y las definiciones de herramientas.
    • Autorización granular por herramienta y una mejor habilitación de capacidades.
  • Otros replican que las empresas ya gestionan miles de endpoints HTTP y que MCP añade cambios constantes y posibles rupturas sin una recompensa clara.

Complejidad, adopción y uso en el mundo real

  • Algunos ven MCP como un intento de “pasarse de listo” al intentar absorber demasiado de HTTP y la autenticación; planean ceñirse a un uso mínimo tipo JSON-RPC.
  • Hay frustración porque el despliegue inicial de MCP involucró múltiples estándares parcialmente superpuestos, diseños muy dependientes del contexto y soporte inconsistente de clientes, lo que erosionó la confianza.
  • Unos pocos siguen viendo MCP como prometedor para casos de uso más acotados e interactivos (por ejemplo, envolver de forma segura APIs privilegiadas, acciones privilegiadas mediante elicitations y reducir los catálogos de herramientas para disminuir la sobrecarga de contexto).