Pi.dev ahora soporta MCP, a pesar de haber dicho que no

Mis respetos al equipo no solo por cambiar de opinión respecto a una creencia firmemente arraigada, sino por hacerlo muy público y no ocultar que es un cambio de postura.

El post enlazado de Armin es oro:

"... siempre que te enfrentas a una opinión muy fuerte sobre un tema, las discusiones razonables sobre ese tema a menudo incluyen argumentos que hace tiempo quedaron obsoletos o que ya no son estrictamente relevantes para la conversación."

(https://lucumr.pocoo.org/2016/11/5/be-careful-about-what-you...)

¡Y eso es de 2016! Hoy en día, si defiendes una postura que adoptaste hace apenas una semana, ya podrías estar desactualizado.

Esta fue la decisión más fácil y muchos como yo la tomamos en marzo[0] en medio de toda la ola de influencers anti-MCP que lo declaraban muerto (muchísimos, muchísimos pesos pesados de la tecnología, incluido Garry Tan). Literalmente todos los influencers tecnológicos en cada feed social en marzo decían que MCP estaba muerto y coronaban a la CLI como ganadora (ignorando por completo todos los argumentos razonables sobre seguridad, observabilidad/telemetría, facilidad de despliegue y operaciones, etc.)

Una cita textual de marzo de 2026[1]:

> Si todavía no estás convencido de que gran parte de este discurso [sobre la muerte de MCP] carece de matices y es puro hype, felicidades por haber picado con el ciclo actual de FOMO de los influencers de IA; nos vemos en 6 meses cuando los influencers pasen a la siguiente revelación del momento para mantenerse relevantes y quedarse con tus ojos y tu dinero.

Era bastante obvio por qué se necesitaría MCP una vez que la ingeniería de IA y su adopción superaran al desarrollador en solitario y al stack de un solo harness de "lo que funciona para mí" frente a "lo que funciona para mi equipo", especialmente en un contexto empresarial. El error clave que cometió la gente fue pensar en términos de sus propios flujos de trabajo y sus propios stacks locales en lugar del flujo de trabajo de un equipo y el stack operativo de un equipo. También había un desconocimiento del modo HTTP sin estado de MCP (sí, ya existía en marzo; la revisión del 2026-07-28 de la especificación simplemente lo prioriza como el enfoque principal de aquí en adelante) frente al `stdio` local.

Mi mayor queja ahora mismo es que OpenAI todavía se ha negado a implementar la especificación de MCP Prompts[2] y en g […]

Aprecio su reticencia hacia MCP, pero /algo/ es mejor que nada.

Es subóptimo por las razones que expone el autor: pero USB-C también lo es. NVME también. HDMI también.

Usamos estas tecnologías enormemente exitosas a pesar de sus defectos porque son ampliamente compatibles y fáciles para el usuario final.

Por eso MCP está en todas partes. Puede que no sea eficiente, robusto y uniforme, pero MEJORARÁ con el tiempo.

Y prefiero mil veces el amplio ecosistema MCP que tenemos ahora que siete u ocho formas diferentes "óptimas" de conectar un LLM a algo útil.

Siento lo mismo sobre la necesidad de soporte para subagentes, me parecen bastante fundamentales.

Sospecho que un modelo inteligente dirigiendo múltiples modelos más tontos para el trabajo y luego usando subagentes con el mismo modelo inteligente para revisión adversarial será un patrón bastante común.

Personalmente, me confundí un poco con que Pi tuviera casi todo eso como plugins, ya que recuerdo el desastre que era Eclipse, donde tanto era simplemente plugins que encajaban de forma floja, y me fui con OpenCode porque cubre la mayoría de mis necesidades de fábrica. Supongo que eso también puede ser señal de que me estoy haciendo mayor, porque mis IDEs y entornos de escritorio también son todos más cercanos a lo estándar.

Tenemos que dejar de ponerles a las empresas nombres sacados del lore de El Señor de los Anillos.

> La forma en que nos gusta pensar en MCP a estas alturas es que debería estar mucho más cerca de OpenAPI con descubrimiento inteligente de herramientas. Eso significa que las herramientas deberían devolver datos estructurados y las herramientas deberían ser descubribles por su documentación y descripción.

OpenAPI es "descubrimiento inteligente de herramientas" (lo que sea que eso signifique). OpenAPI literalmente "devuelve datos estructurados" y es "descubrible por su documentación y descripción".

Una vez, solo una vez, me gustaría ver a alguien explicar MCP en términos que sugieran que tiene alguna idea de lo que está hablando.

Uso mcporter[0] para consumir MCP cuando no hay CLIs adecuadas disponibles. Expone los MCP como comandos de shell. Los agentes componen usando primitivas estándar de shell. ¿La herramienta devuelve json? Lo pasas por pipe a jq.

Otra ventaja es que me permite ejecutar herramientas exactamente de la misma forma que los agentes, en lugar de tratar MCP como una forma especial de llamar a servicios. Súper valioso al depurar.

[0] https://mcporter.sh/

¿Todavía no entiendo MCP? ¿Qué puede hacer MCP que una skill + cli no pueda? He estado usando hax (https://usehax.dev) y no he echado de menos las skills para nada, la verdad.

¡No tenía ni idea de que pi no soportaba MCP! Soy un usuario nuevo, acabo de empezar a trastear con él. Estaba poniendo a punto mis herramientas e intenté hacer funcionar uno de mis MCP de base de datos (lo cual, en retrospectiva, parecía un poco doloroso, pero supongo que asumía que era mi responsabilidad construir y mantener esas conexiones).

Otra nota retrospectiva: "No MCP" parece ser el primer icono en su página principal, no sé cómo se me pasó.

¡Imagínate mi sorpresa al leer esto!