Dijiste no MCP

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

Pi, un arnés minimalista de agente de codificación, está revirtiendo su postura anterior de “no MCP” al añadir soporte integrado para el Model Context Protocol y una nueva capa de scripting “Codemode”, lo que ha desatado el debate sobre si esto socava su filosofía original. Los comentaristas contrastan MCP con las CLIs tradicionales y las APIs estilo OpenAPI, discutiendo sobre componibilidad, seguridad, gobernanza empresarial y cómo deben exponerse las herramientas a LLMs y agentes. Muchos ven MCP y Codemode como compromisos pragmáticos que encajan con cómo se entrenan los modelos modernos y cómo operan realmente los equipos, mientras que otros se preocupan por la acumulación de funciones y la proliferación de estándares superpuestos.

Qué es MCP y por qué es controvertido

  • MCP (Model Context Protocol) se describe como una forma estandarizada para que los agentes/LLMs descubran y llamen herramientas/APIs, incluyendo autenticación, documentación y metadatos estructurados de herramientas.
  • Sus partidarios lo ven como “API + docs” o “RPC auto-documentado” que hace que las herramientas sean descubribles y más fáciles para usuarios promedio e interfaces de “IA de consumo” (ChatGPT, Claude, etc.).
  • Los críticos argumentan que gran parte de esto podría haberse hecho extendiendo OpenAPI o los IDL existentes; algunos lo ven como NIH y redundante frente a “CLI + skills” o REST.

Cambio de filosofía de Pi: de “No MCP” a MCP integrado

  • Pi se valoraba originalmente como un arnés de codificación minimalista, altamente personalizable y estilo yolo: sin modelo de permisos, sin MCP, un núcleo muy básico con extensiones para todo.
  • Algunos usuarios acogen MCP en el núcleo porque MCP se ha vuelto común en empresas y otros arneses; usar extensiones para una capacidad tan central parecía incómodo.
  • Otros temen que esto sea el comienzo de una hinchazón de funciones y un alejamiento de “este arnés es tuyo” hacia “producto de codificación con opiniones”, especialmente con otras ofertas comerciales a su alrededor.
  • Los mantenedores enfatizan que no se habilita nada nuevo por defecto; las funciones pueden desactivarse o mantenerse como extensiones/forks.

Codemode: ¿por qué no simplemente Bash?

  • Codemode es un entorno de scripting aislado (a menudo JS/TS) para orquestar llamadas a herramientas y MCP a nivel de arnés.
  • Quienes lo defienden:
    • Menos idas y vueltas al modelo, menos tokens, mejor paralelización.
    • Funciona en entornos sin acceso a shell y permite modelos de permisos distintos de las cuentas del SO.
    • Permite componer herramientas MCP dentro de un solo sandbox en lugar de que cada servidor MCP tenga el suyo propio.
  • Los escépticos:
    • Los modelos ya encadenan bash/Python extraordinariamente bien; añadir codemode parece reinvención y complejidad.
    • Para agentes de codificación locales, un shell restringido en una VM/contenedor aislado puede ser más simple y transparente.
    • Codemode resuelve principalmente problemas creados por MCP/diseño de arnés, no limitaciones inherentes.

MCP vs CLI/skills/OpenAPI y empresa vs local

  • Lado de “equipo/empresa”:
    • MCP sobre HTTP ofrece autenticación centralizada, flujos OAuth, telemetría, skills/prompts revocables y distribución/versionado más fácil de herramientas entre muchos usuarios.
    • Algunos usan prompts/recursos MCP para gestionar centralmente comandos tipo / y pequeño estado compartido.
  • Lado “local/usuario avanzado”:
    • CLI + skills son más fáciles de depurar, componibles vía bash y funcionan con cualquier arnés que admita herramientas de shell.
    • MCP puede inflar el contexto, se implementa de forma inconsistente entre clientes y va rezagado en aspectos básicos como la carga de archivos.
  • Hay acuerdo en que MCP está mejorando (HTTP sin estado, mejores herramientas) pero desacuerdo sobre si es fundamentalmente necesario o solo otro estilo de API.

Subagentes, contexto y componibilidad

  • Algunos dependen mucho de subagentes y sesiones separadas para gestionar contexto y coste; otros encuentran los subagentes opacos, poco amigables con la caché y prefieren sesiones largas únicas más compactación personalizada.
  • “MCP no compone” se debate:
    • Una visión: codemode más sandboxes a nivel de arnés arregla en gran medida la composición de múltiples MCP.
    • Otra: un diseño correcto de herramientas y REST/HATEOAS podría ofrecer mejor descubrimiento incremental y composición que los patrones actuales de MCP.

Meta: ciclos de hype e influencers

  • Varios comentarios critican la ola anterior de “MCP está muerto, ganó CLI” como hype impulsado por influencers, ahora invertido a medida que crece la adopción de MCP.
  • Algunos ven MCP vs CLI en parte como algo cultural: desarrolladores orientados a UNIX local frente a empresas y usuarios que no usan terminal.
  • El sentimiento general: MCP no es ni magia ni inútil; es una compensación que encaja mejor con algunas pilas (especialmente empresa/interfaz gráfica) que con otras (desarrollo local con shell).