Pi, el agente de código minimalista, rectifica y añade MCP

Cuatro herramientas: `read`, `write`, `edit` y `bash`. Con ese inventario mínimo se presentó Pi, el agente de programación para terminal que Mario Zechner, creador del framework de videojuegos libGDX, desarrolla como código abierto en el repositorio pi-mono. Entre sus renuncias deliberadas había una que llamaba la atención en plena expansión del protocolo: nada de MCP.

Esa negativa ha caducado. Según The Register, Pi ha dado un giro de 180 grados y añade soporte para Model Context Protocol. El cambio pesa más de lo que parece, porque Zechner había sido una de las voces más claras contra el uso de MCP en agentes de código, hasta el punto de titular uno de sus textos «What if you don't need MCP at all?».

De dónde venía Pi

Pi nació como reacción a agentes cada vez más cargados de funciones. Su propuesta era un system prompt corto, sin subagentes integrados ni modo plan, con soporte para varios proveedores de modelos y un sistema de extensiones en TypeScript para que cada usuario añadiera solo lo que necesitara. Esa base ligera es también la que OpenClaw usa como núcleo, de modo que las decisiones de diseño de Pi tienen un alcance mayor que el de su propia comunidad.

El argumento contra MCP era sobre todo de coste de contexto. Servidores populares como el de Playwright o el de Chrome DevTools cargan más de una veintena de definiciones de herramientas en cada sesión, y esos tokens se consumen antes de que el agente haga nada útil. La alternativa que defendía Zechner era escribir pequeñas herramientas de línea de comandos acompañadas de un README que el agente lee solo cuando las necesita, una idea muy cercana a la de las skills de Claude Code.

Por qué el giro tiene sentido

Han cambiado dos cosas. La primera es el peso del estándar. MCP, creado por Anthropic y cedido en diciembre de 2025 a la Agentic AI Foundation bajo el paraguas de la Linux Foundation, se ha convertido en la forma habitual de exponer servicios a un modelo. GitHub, Linear, Notion o Sentry publican servidores MCP propios, y un agente que no habla el protocolo obliga a su usuario a reconstruir cada integración a mano.

La segunda es que el problema del contexto tiene ahora respuestas parciales. Anthropic explicó en noviembre de 2025, en su artículo sobre ejecución de código con MCP, que un agente que trata los servidores como APIs invocadas desde código, en lugar de cargar todas las definiciones de golpe, puede pasar de 150.000 a 2.000 tokens en un flujo de ejemplo, una reducción del 98,7%. Claude Code, por su parte, ya carga las herramientas MCP bajo demanda cuando sus definiciones ocupan demasiado contexto. La objeción de Zechner sigue siendo válida, pero ya no obliga a elegir entre estándar y eficiencia.

Queda por ver cómo encaja el soporte con la filosofía de extensiones de Pi y cuánto contexto consume por defecto. Para un proyecto que hizo de la contención su seña de identidad, la forma de activarlo importa tanto como el soporte en sí. Ahí estará la diferencia entre una concesión pragmática y una renuncia a la idea original.

Para quién es útil

Usuarios de Pi que ya mantenían servidores MCP para Claude Code o Claude Desktop. Al tratarse de un protocolo estándar, esos servidores deberían funcionar sin reescribirse, aunque la configuración cambie de una herramienta a otra.
Equipos que publican servidores MCP, que suman un cliente más con una base de usuarios técnica y muy atenta al consumo de tokens.
* Quien diseña agentes propios, porque el caso de Pi muestra que incluso las posturas más minimalistas acaban negociando con la interoperabilidad.

Hemos visto el mismo dilema en proyectos con clientes: cada servidor MCP conectado facilita una integración y, a la vez, ocupa espacio que el modelo necesita para trabajar. Nos parece una rectificación razonable; lo que conviene conservar de la postura original de Zechner es la disciplina de que cada servidor justifique los tokens que cuesta.