Por qué MCP siempre fue una mala idea

Recientemente asistí a un evento de todo el día centrado en lo último y lo mejor del mundo MCP. Si bien todos los presentadores fueron increíbles y parecían apasionados por el trabajo que estaban haciendo, honestamente estoy cansado de MCP. Es un protocolo horrible construido para una época en que los LLM no eran tan inteligentes, y lo hemos superado.

Breve historia

MCP se lanzó en noviembre de 2024 por el equipo de Anthropic como un protocolo diseñado para ayudar a los agentes a conectarse a servicios y fuentes de datos externos. Los modelos de la época seguían siendo relativamente primitivos, al menos comparados con lo que tenemos ahora. Ni siquiera teníamos Claude Code en ese entonces, y los flujos de trabajo agenticos de propósito general eran mucho menos fiables. Los usuarios empezaron a ver la utilidad de dar a sus modelos de IA acceso a servicios externos. Esto permitió un nivel de productividad que no habíamos visto antes. Vimos una explosión en la adopción de MCP, coincidiendo con un crecimiento similar, si no más explosivo, en la adopción de LLM en toda la economía. Con el tiempo, MCP continuó evolucionando bajo la tutela de Anthropic antes de ser eventualmente donado a la Agentic AI Foundation, bajo la Linux Foundation, en 2025.

El complejo industrial MCP

Con el enorme crecimiento en la adopción, los usuarios empezaron a agregar muchos servidores MCP a sus configuraciones, y empezaron a toparse con el problema de la hinchazón de contexto. Cada servidor vendría con múltiples herramientas, cada una con su propio esquema, lo que empezó a sobrecargar el contexto de todos estos modelos. Los desarrolladores de Harness encontraron muchos trucos para sortear esto, incluidos patrones genéricos de búsqueda/ejecución que ahora ofrecen plataformas como Composio, Mint MCP y Pipedream. Todos ellos resuelven efectivamente el problema de tener un solo lugar para poner tus credenciales para los diversos servicios externos y darle a tu agente un conjunto mínimo de herramientas (para reducir la hinchazón de contexto) que puede usar para acceder a ellos. Quiero dejar claro que esto es algo bueno, a corto plazo.

Con todas las cosas que hemos construido alrededor de MCP, lo que no tuvimos en cuenta, o tal vez ignoramos, es que los modelos mejoraban. Ahora tenemos sistemas completos dedicados a monitorear servidores MCP, asegurarnos de que las respuestas sean buenas, asegurarnos de que los agentes puedan acceder fácilmente a las herramientas, averiguar esquemas y determinar qué necesitamos dar a los agentes para que puedan hacer la llamada correcta en el momento adecuado.

Sorpresa, sorpresa, los grandes laboratorios tenían razón

Los modelos mejoraron. Ahora son capaces de ejecutar código en una computadora, razonar sobre grandes bases de código y, en general, actuar de manera mucho más autónoma que nunca. Una gran parte de ese trabajo fue escribir/ejecutar scripts con fines de codificación. Un efecto secundario (¿lo es?) es que ahora son buenos llamando APIs directamente. Pueden escribir scripts, componer múltiples servicios diferentes y llamar APIs que nunca han visto antes, todo en flujos de trabajo útiles con mínima intervención del usuario.

Los LLM se han vuelto tan buenos en esto, que Cloudflare incluso lanzó Code Mode, una mejor forma de usar MCP haciendo que los LLM compongan las diversas llamadas en scripts que pueden ejecutarse en un sandbox. Pero incluso mejor que eso, los LLM han descubierto cómo usar el comando --help para descubrir CLIs, por lo que ya no necesitan servidores MCP para acceder a muchos servicios disponibles a través de APIs documentadas o CLIs. La mayoría de los servidores MCP de servicios remotos en última instancia envuelven APIs que ya existen.

¿Y ahora qué?

Eliminamos la mayoría de nuestros servidores MCP. Eso es todo. Los agentes con acceso a terminal pueden reemplazar la mayoría de los servidores MCP y a menudo son más capaces.

Todavía hay algunos problemas, como que las CLIs devuelvan respuestas legibles por máquina (JSON/XML, etc.), que tienden a ser muy verbosas y pesadas en uso de tokens, pero tenemos formas de solucionar esto. Gran parte de la alternativa ya existe: APIs HTTP documentadas, negociación de contenido estándar y mecanismos de autenticación maduros. Deberíamos empezar a estandarizar cómo los agentes usan APIs HTTP directamente. Por ejemplo, los clientes de agentes podrían adjuntar encabezados para identificarse como agentes, y los servidores podrían enviarles automáticamente datos de respuesta como Markdown o texto en lugar de HTML o....