El problema fundamental que MCP intentó resolver fue la incapacidad de los Large Language Models (LLMs) primitivos para interactuar directamente con servicios externos y fuentes de datos. En 2024, cuando los LLMs carecían de capacidades avanzadas de razonamiento y ejecución de código, MCP proporcionó una capa de abstracción para que los agentes pudieran acceder a herramientas y APIs. Esto permitió una explosión en la productividad y la adopción de agentes.
Sin embargo, la rápida evolución de los LLMs ha superado la necesidad de MCP. Los modelos actuales son capaces de generar y ejecutar código, razonar sobre bases de código extensas y llamar APIs directamente, incluso aquellas que no han visto antes. Esta capacidad intrínseca de los LLMs para interactuar con interfaces programáticas estándar (HTTP APIs, CLIs) hace que el protocolo MCP, con su sobrecarga de contexto y complejidad, sea redundante. La tesis central es que la madurez de los LLMs ha desplazado la necesidad de protocolos intermedios, abogando por una interacción directa y estandarizada con la infraestructura existente de la web.
Históricamente, la creación de protocolos de abstracción es común cuando una tecnología emergente carece de capacidades para interactuar con sistemas maduros. MCP es un ejemplo de esto, similar a cómo los primeros sistemas distribuidos requerían RPCs altamente acoplados antes de la estandarización de HTTP/REST. La evolución de los LLMs refleja un patrón de maduración tecnológica donde las capacidades se internalizan, reduciendo la necesidad de capas de adaptación externas.
Arquitectura del Sistema
La arquitectura original basada en MCP implicaba que los agentes LLM interactuaran con 'servidores MCP'. Estos servidores actuaban como proxies o adaptadores, exponiendo un conjunto de 'herramientas' con sus respectivos esquemas a los LLMs. Cada herramienta encapsulaba la lógica para interactuar con un servicio externo o una API. El problema principal de esta arquitectura era el 'context bloat': la necesidad de cargar los esquemas de múltiples herramientas en el contexto del LLM, lo que consumía tokens y reducía la eficiencia.
Para mitigar el 'context bloat', surgieron plataformas que implementaban patrones de 'generic search/execute'. Estas plataformas centralizaban las credenciales y presentaban un conjunto mínimo de herramientas al agente, que luego podía buscar y ejecutar las herramientas necesarias dinámicamente. Sin embargo, esta solución añadía otra capa de complejidad y monitoreo (servidores MCP, monitoreo de respuestas, gestión de esquemas).
La arquitectura propuesta para reemplazar MCP es una interacción directa del agente LLM con HTTP APIs y CLIs existentes. Esto implica que el LLM genera directamente las solicitudes HTTP (GET, POST, etc.) o comandos CLI, interpreta las respuestas y compone flujos de trabajo. La estandarización se centraría en cómo los agentes se identifican (ej. User-Agent específico o X-Agent-Client header) y cómo solicitan formatos de respuesta optimizados para LLMs (ej. Accept: text/markdown para documentación, o formatos JSON/XML más concisos). Esto elimina la necesidad de los servidores MCP, reduciendo la superficie de ataque, la latencia y la complejidad operativa.
Flujo de Interacción Agente-Servicio (Pre-MCP)
- 1 Agente LLM Intenta acceder a un servicio externo.
- 2 Servidor MCP Recibe la solicitud del agente, interpreta la intención.
- 3 Servidor MCP Selecciona la herramienta adecuada y su esquema.
- 4 Servidor MCP Realiza la llamada a la API externa.
- 5 API Externa Procesa la solicitud y devuelve la respuesta.
- 6 Servidor MCP Formatea la respuesta para el contexto del LLM.
- 7 Agente LLM Recibe y procesa la respuesta formateada.
Flujo de Interacción Agente-Servicio (Post-MCP)
- 1 Agente LLM Razona sobre la necesidad de interacción externa.
- 2 Agente LLM Genera script/comando CLI/solicitud HTTP directa.
- 3 Sandbox/Terminal Ejecuta el script/comando o realiza la solicitud HTTP.
- 4 API Externa/CLI Procesa la solicitud y devuelve la respuesta (ej. JSON, Markdown).
- 5 Agente LLM Interpreta directamente la respuesta (ej. JSON, Markdown).
| Capa | Tecnología | Justificación |
|---|---|---|
| networking | HTTP/1.1, HTTP/2 | Protocolo de comunicación subyacente para la interacción directa con APIs. Su ubicuidad y estandarización lo hacen ideal para la comunicación agente-servicio. vs gRPC, SOAP Uso de headers estándar como `Accept` para content negotiation y `User-Agent` para identificación de agentes. |
| data-processing | JSON, XML, Markdown | Formatos de datos para el intercambio de información entre agentes y servicios. La preferencia por Markdown o JSON conciso reduce el uso de tokens en el contexto del LLM. vs YAML, Protocol Buffers Servidores que implementan `Accept: text/markdown` para respuestas optimizadas para LLMs. |
| security | OAuth 2.0, API Keys | Mecanismos de autenticación y autorización para que los agentes accedan a servicios externos de forma segura. Estos son mecanismos maduros y bien establecidos. vs Custom token schemes |
| compute | Sandbox/Container Runtimes | Entornos aislados para la ejecución de código generado por LLMs (scripts, comandos CLI), mitigando riesgos de seguridad y garantizando un entorno controlado. vs VMs, Serverless functions Cloudflare Code Mode como ejemplo de ejecución sandboxed. |
Trade-offs
Ganancias
- ▲ Reducción de la complejidad del sistema
- ▲ Menor 'context bloat' en LLMs
- ▲ Mayor autonomía y capacidad de los agentes
- ▲ Reutilización de infraestructura web existente
Costes
- △ Necesidad de LLMs más capaces
- △ Mayor carga de procesamiento en el LLM para interpretar respuestas complejas
- △ Dependencia de la estandarización de APIs para agentes
Fundamentos Teóricos
Este escenario de obsolescencia de un protocolo debido a la evolución de las capacidades de los agentes se alinea con principios de diseño de sistemas distribuidos y la ley de Conway. La ley de Conway postula que las organizaciones diseñan sistemas que reflejan sus propias estructuras de comunicación. En este caso, la estructura inicial de los LLMs (menos capaces) llevó a la creación de una capa de comunicación (MCP) que ahora es redundante debido a la evolución de la 'organización' interna del LLM.
Desde una perspectiva más fundamental, la capacidad de los LLMs para razonar y ejecutar código se relaciona con el concepto de 'Turing Completeness' y la capacidad de los sistemas para simular otros sistemas. Al ser capaces de generar y ejecutar scripts, los LLMs están efectivamente 'simulando' la lógica que antes residía en los servidores MCP. Esto también se conecta con el trabajo en 'program synthesis' y 'automated reasoning', donde los sistemas de IA aprenden a generar programas o secuencias de acciones para lograr un objetivo, eliminando la necesidad de interfaces predefinidas y rígidas. La evolución de los LLMs hacia la interacción directa con APIs es una manifestación de su creciente autonomía y capacidad de 'programación' ad-hoc, un concepto explorado en la investigación de IA desde los primeros días de la planificación y resolución de problemas.