MCP (Model Context Protocol): El 90% lo Trata Como un "USB-C para IA" — y el Talón de Aquiles es la Ventana de Contexto

*El verdadero problema de MCP no es conectar herramientas. Es que cada tool call devora contexto como si no hubiera un mañana. *

Todo el mundo está emocionado con MCP como el "USB-C para la IA". Un protocolo abierto que estandariza cómo los modelos de lenguaje descubren e invocan herramientas externas. Suena bien. Es open source. Anthropic lo impulsa.

Después de construir 6 servidores MCP en producción, he descubierto que la mayor ventaja del protocolo no es el acceso a herramientas. Es algo de lo que nadie habla.

*El hype asume que el acceso a herramientas es el problema difícil. Pero el acceso ya estaba resuelto con function calling. Lo genuinamente duro es decidir qué herramientas llamar, en qué orden y cómo comprimir sus respuestas en ventanas de contexto limitadas. *

Y MCP, en su especificación actual, no aborda nada de eso.

---

El Problema Que Nadie Está Midiendo: El Impuesto de Contexto

Cada llamada a una herramienta MCP consume tokens. No solo los tokens de la respuesta — también los del wrapper JSON-RPC, las cabeceras de transporte y los metadatos del esquema.

Monta un servidor MCP que devuelva una fila de base de datos de 10KB. MCP la envuelve con metadatos del esquema, campos de error y framing de transporte. *El resultado puede duplicar el consumo de tokens. *

En una ventana de contexto de 128K tokens, tres llamadas a herramientas verbosas pueden consumir el 40% de tu presupuesto antes de que el modelo empiece siquiera a razonar sobre la respuesta.

Esto no es teoría. Es lo que pasa cuando pones MCP en producción sin medir.

Ejecuta esto. El ratio te va a doler.

---

MCP vs Function Calling Nativa: La Tabla de la Verdad

El argumento a favor de MCP es la estandarización. Cualquier cliente MCP puede hablar con cualquier servidor MCP. Pero el coste es latencia y tokens.

| Aspecto | Function Calling Nativa | MCP |

|---|---|---|

| Descubrimiento de tools | En el schema del modelo | Handshake JSON-RPC + tools/list |

| Invocación | In-process | stdio o HTTP (serialización) |

| Overhead de tokens | Mínimo | Wrapper + metadatos + transporte |

| Latencia (sub-100ms) | Instantánea | +20-50ms por salto de transporte |

| Multi-servidor | No soportado | Sí, pero sin orquestación |

❌ MCP para tiempo real: Si tu app necesita responder en menos de 200ms, el overhead del protocolo te mata.

✅ MCP para herramientas internas: Si controlas cliente y servidor y tu ventana de contexto es generosa, funciona bien.

*El problema es que la mayoría lo usa para el caso equivocado. *

---

El Problema de Orquestación Multi-Servidor Que Nadie Resuelve

La arquitectura de MCP asume un único servidor con una lista plana de herramientas. En producción, necesitas componer herramientas entre servidores: base de datos, sistema de ficheros, API gateway, Slack.

No hay un mecanismo integrado para:

Enrutamiento prioritario: Qué servidor responde primero cuando dos pueden manejar la misma petición
Rate limiting entre servidores: Un servidor lento no debe bloquear a los demás
Resolución de dependencias: La herramienta A necesita el resultado de la herramienta B, pero están en servidores distintos

Los early adopters están construyendo sus propias capas de orquestación. *Eso derrota el propósito de la estandarización. *

---

La Primitiva Que Falta: Selección de Herramientas Consciente del Contexto

MCP estandariza el descubrimiento de herramientas. Puedes listar todas las herramientas con sus esquemas. Pero no hay forma de que el servidor exprese prioridad de contexto.

Necesitas poder decir:

"Esta herramienta es cara. Llámala con moderación."
"Este endpoint devuelve 500KB. Solo úsalo si es estrictamente necesario."
"Esta consulta es lenta. Prefiere la versión cacheada."

Sin esta primitiva, los clientes o exponen todo y confían en que el modelo elija bien, o hardcodean limitaciones que replican la fragmentación que MCP pretendía resolver.

Este patrón no está en la especificación de MCP. Te toca construirlo tú.

---

El Framework de 4 Capas para MCP en Producción (FCMP)

Después de 6 servidores MCP, he destilado el patrón que funciona. Lo llamo Framework de Contexto MCP en Producción (FCMP) . Son 4 capas:

1. Capa de Caché con TTL

Cada tool call debería cachearse. No tiene sentido pedir los mismos datos de base de datos cada vez que el modelo pregunta.

2. Capa de Presupuesto de Contexto

Antes de ejecutar una tool call, estima cuánto contexto va a consumir. Si no cabe en la ventana disponible, no la ejecutes.

3. Capa de Exposición Selectiva

No expongas todas las herramientas a la vez. Crea un gateway que decida qué tools están disponibles según el estado de la conversación.

4. Capa de Compresión de Respuestas

Si una tool devuelve 50KB de datos, trúncalos o resúmelos antes de devolverlos al modelo. El modelo no necesita las 50 facturas — necesita el total y la fecha de la última.

---

MCP es Fuerte para Tools Internas, Débil para Apps de Consumo

El protocolo brilla en IDEs, herramientas CLI y pipelines de automatización donde controlas tanto el cliente como el servidor. Para apps orientadas al consumidor, con sensibilidad a latencia y entrada impredecible, el overhead del handshake de inicialización y la negociación de transporte añade un retraso inaceptable.

Vale para: editores de código, asistentes de terminal, pipelines CI/CD, herramientas internas de datos.

No vale para: chatbots en tiempo real, apps móviles, APIs públicas con SLAs estrictos.

---

Conclusión: MCP Resuelve el Problema Fácil. La Ventana de Contexto Sigue Siendo Tu Problema

MCP es un protocolo útil. Su apertura es su mejor argumento frente al vendor lock-in de function calling propietario. Pero los estándares abiertos ganan resolviendo los problemas difíciles, no solo los fáciles.

La especificación actual resuelve el descubrimiento de herramientas (problema ya resuelto por function calling) y evita la gestión de estado, el presupuesto de contexto y la compresión de resultados — *los problemas genuinamente duros. *

Si despliegas MCP hoy, mide el impuesto de contexto. Construye la capa de caché. Implementa la exposición selectiva. No esperes a que el protocolo lo resuelva por ti.

*El USB-C para la IA es bonito. Pero si cada vez que conectas un dispositivo se te vacía la batería, el conector no es el problema. *

MCP (Model Context Protocol): El 90% lo Trata Como un "USB-C para IA" — y el Talón de Aquiles es la Ventana de Contexto