Hay algo profundamente sano en admitir que te equivocaste, sobre todo en software, donde cambiar de opinión suele leerse como debilidad. Esta semana el equipo detrás de Pi, un harness de agentes de IA que había sido abiertamente despreciador del protocolo MCP —llegaron a tener un letrero en su web que decía «no soportamos MCP» y más de una burla en podcasts— publicó un post explicando que lo integraron al core. El texto se escribió como una confesión y generó una conversación enorme en Hacker News, porque toca algo que todos los que trabajamos con agentes llevamos tiempo masticando.
El problema nunca fue MCP, eran los servidores
El razonamiento de su mea culpa es honesto: el mundo no es estático. El MCP de hoy no es el de hace un año, y quedarse fuera por capricho de principios es tan absurdo como dejar de usar git porque su creador era un arrogante en 2005. Pero lo interesante no es la capitulación, sino el diagnóstico que la acompaña: MCP sigue siendo terrible para componer herramientas. La mayoría de los servidores MCP que hay afuera están diseñados para harnesses que tiran todas las herramientas al contexto y celebran devolver texto plano, como si el contexto del modelo fuese gratis e infinito.
Cualquiera que haya dejado caer cuarenta herramientas dentro del contexto de un agente sabe cómo termina: el modelo empieza a confundir el catálogo con la tarea, quema tokens describiendo APIs que no va a usar, y a la cuarta llamada encadenada ya no sabe qué respondió la primera. Yo viví exactamente eso montando mis propios flujos con cron: agrego una herramienta, el agente se pone tonto, la saco, todo vuelve a funcionar. No era un problema del protocolo ni del modelo; era una arquitectura de contexto mal resuelta.
Codemode: la parte que de verdad me interesa
La solución que adoptaron apunta a donde creo que va todo esto: en vez de exponer las herramientas crudas al modelo se abre un sandbox de JavaScript donde el agente escribe código que orquesta las llamadas, y el estado de esa orquestación vive en la transcripción de la sesión, no en el contexto del modelo. El resultado práctico es el que muestran en su ejemplo: el agente revisa cientos de issues en un tracker, le pide a un modelo clasificador pequeño que califique el tono de cada hilo, corre los workers en paralelo y devuelve un resumen de tres líneas. Nunca una sola respuesta intermedia pasa por el contexto del chat.
Esto es básicamente la misma idea del tool use programático —cargar herramientas bajo demanda, dejar que el agente componga en lugar de memorizar— que ya se está imponiendo en varios harnesses, y me alegra, porque valida algo que empecé a aplicar en mi propia infra hace un tiempo: menos herramientas visibles, más composición. Es la misma lección de cuando puse mis API keys regadas por seis scripts detrás de una sola puerta: la solución no era administrar mejor el desorden, era cambiar dónde vive el desorden.
Sobre rendirse con elegancia
Mi opinión es que «no soportamos MCP» nunca fue una promesa de producto; era un statement de marca que funcionó mientras el ecosistema era una feria de servidores mediocres. Cuando eso cambió, sostener el rechazo por orgullo convertía la postura en religión. Y una religión no compila. Lo rescatable del episodio es el método: monitorear lo que criticas, reevaluar con datos, y cuando cambias, explicar exactamente qué cambió para no dejar a tu comunidad mirando un letrero roto. Ojalá más proyectos operaran así, porque en la industria de la IA media las guerras de estándares son puro ego con README.
La moraleja práctica para quien arma agentes hoy: no le temas al estándar que despreciaste. Temele al patrón de gastar tu contexto describiendo herramientas en vez de usarlas. Eso no cambia con las versiones.
Fuente del tema: You Said No MCP!, del blog de Earendil.
Fuente de inspiración: You Said No MCP!
