¿MCP siempre fue una mala idea?

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

Los críticos del Model Context Protocol (MCP) sostienen que fue sobrevalorado y que a menudo desperdicia tokens frente a simplemente permitir que los agentes de IA usen APIs HTTP bien diseñadas o herramientas CLI, especialmente ahora que los modelos entienden mejor las interfaces. Los defensores responden que MCP sigue resolviendo problemas importantes de autenticación, acceso con mínimo privilegio, sandboxing, auditabilidad y descubrimiento estandarizado de herramientas, en particular en entornos empresariales y multiusuario donde no se puede dar a un agente acceso al shell o claves API sin más. El intercambio destaca una división más amplia: los flujos de trabajo individuales o locales suelen favorecer las CLI y las APIs directas, mientras que los casos de uso organizacionales y web cada vez recurren más a estándares estilo MCP y a variantes emergentes como WebMCP.

MCP frente a CLI / APIs directas

  • Muchos sostienen que las CLI y REST/OpenAPI ya resuelven la mayoría de los problemas a los que apunta MCP; las CLI son familiares, componibles y a menudo más baratas en tokens.
  • Otros dicen que MCP es, en la práctica, “REST para agentes”: una interfaz estándar y descubrible para herramientas, mejor alineada con la forma en que los agentes llaman a herramientas hoy.
  • Algunos ven los servidores MCP como envoltorios ligeros sobre APIs/CLI existentes (“lipstick on a pig”), que añaden infraestructura extra sin nueva semántica.

Seguridad, autenticación y mínimo privilegio

  • Hay un fuerte apoyo a MCP en torno a la autenticación: puede ocultar credenciales a los agentes, centralizar la autenticación y exponer solo operaciones estrechas y validadas.
  • Los críticos responden que un buen diseño de API, tokens de corta duración con alcance limitado, proxies o CLI en sandbox pueden lograr lo mismo; MCP no es intrínsecamente más seguro.
  • Existe la preocupación de que confiar en MCP para el control de acceso pueda crear una falsa sensación de seguridad; siguen siendo necesarios controles del lado del servidor y auditoría.

Uso de tokens, contexto y rendimiento

  • Varios informan que los MCP consumen más tokens que el uso directo de CLI/API (especialmente los mal implementados); otros afirman lo contrario cuando los esquemas MCP son estrictos.
  • El antiguo diseño de MCP, que cargaba demasiado en el contexto, es ampliamente criticado; las variantes nuevas “stateless / progressive” se consideran mejoras.
  • La sobrecarga de arranque de procesos para las CLI generalmente se considera insignificante en comparación con la latencia del LLM o de la red.

Empresa, gobernanza y uso en el mundo real

  • MCP se considera más valioso en entornos empresariales y multiusuario: control centralizado, registros de auditoría, revocación/rotación de secretos, interfaz uniforme entre runtimes.
  • Las tiendas de plugins de MCP en grandes apps de chat impulsan la adopción entre usuarios no técnicos; algunos ven esto como parte de una “burbuja” de IA.

Estándares, alternativas y WebMCP

  • Varios argumentan que estándares existentes (REST, OpenAPI/Swagger, SOAP/WSDL, encabezados HTTP, documentación .well-known) podrían haberse ampliado en lugar de inventar MCP.
  • WebMCP es elogiado como un enfoque más simple y alineado para aplicaciones web, con potencial para suplantar al MCP “clásico” en ese ámbito.
  • Alternativas mencionadas: harnesses centrados en CLI, sandboxes/VMs personalizados, AXI y herramientas genéricas de “hacer una solicitud HTTP” con buenas especificaciones.

Sentimiento general

  • Consenso: MCP no es universalmente malo, pero sí está sobrevalorado y se usa mal.
  • Heurística aproximada del hilo: para desarrollo individual o local, las CLI + APIs suelen bastar; MCP resulta atractivo cuando necesitas estandarización entre herramientas, acceso remoto y gobernanza centralizada.