MCP no es un Protocolo de Tool-Calling. Es la Pelea por Quién Controla el Runtime del Agente

La mayoría lo trata como una API más bonita. Ese es el error que te va a costar el foso

En 2024 Anthropic publicó un protocolo abierto. En cuestión de meses, OpenAI, Google y Microsoft lo adoptaron. Sin embargo, el 90% de los desarrolladores lo usa como una versión más elegante de function calling.

*MCP no es una forma de llamar a una API desde un LLM. Es una toma de poder silenciosa sobre quién controla el runtime del agente. *

El marco mental dominante es: "MCP = herramienta para que el modelo haga llamadas". Esa lectura te deja ciego a lo estructural.

Miremos los tres primitivos que define MCP — tools, resources y prompts — y entenderás por qué casi todo tutorial que has visto se queda en la superficie.

Tools, Resources y Prompts: el dato que ningún tutorial explica

Casi todo el material que circula sobre MCP se centra en tools. Es lo más fácil de entender y lo más parecido a lo que ya conoces de function calling. Pero es justo ahí donde la gente pierde el punto.

Un servidor MCP expone tres primitivos, no uno:

Tools: acciones iniciadas por el modelo. Leer, escribir, ejecutar. Es el caso que todo el mundo enseña.
Resources: contexto que inyecta el host, no el modelo. Ficheros, esquemas, documentación. El modelo los lee sin tener que "llamar" a nada.
Prompts: plantillas reutilizables que invoca el usuario o el host. Flujos de trabajo repetibles, no respuestas ad-hoc.

La implicación práctica es brutal. Si tu integración solo expone tools, obligas al modelo a decidir cuándo traer contexto. Eso convierte la fiabilidad y la latencia de todo el loop del agente en un juego de adivinanzas con el LLM.

Con resources, el control de contexto lo tiene la aplicación. No esperas a que el modelo "piense" en llamar a una función. Le entregas el contexto antes de que pregunte.

Y con prompts, defines flujos completos reutilizables. El usuario invoca una plantilla, no un endpoint suelto.

❌ Tool-only: el modelo debe adivinar qué contexto necesita y cuándo pedirlo. Latencia impredecible, contexto que se pierde, loops que se desvían.

✅ Tools + Resources + Prompts: el host inyecta contexto, el modelo ejecuta acciones y el usuario reutiliza flujos. Determinista donde importa.

El código que casi nadie escribe

Este es un servidor MCP mínimo en Python con FastMCP. Fíjate en lo que hace el framework por ti — JSON-Schema validado, transporte, concurrencia:

Tres líneas para una tool. Diez para un servidor completo con contexto controlado por app y flujos reutilizables. Ese es el poder real de MCP: esconde la fontanería y deja que el diseño hable.

El host, no el modelo, es ahora el producto

Esto es lo que la gente se pierde al llamar a MCP "tool-calling".

Function calling es fontanería modelo-a-API dentro del stack de un solo vendor. Tu modelo, tu API, tu formato de serialización. Cerrado por definición.

MCP es un contrato neutral y agnóstico del host. Cualquier agente — Claude, Cursor, Copilot, un agente custom tuyo — se conecta a cualquier capacidad — GitHub, Slack, PostgreSQL, tu API interna — sin pegamento escrito a medida.

Consecuencia: el usuario conserva sus herramientas y cambia el agente que tiene delante. Hoy uso Cursor con mi servidor de GitHub. Mañana cambio a un cliente custom con el mismo servidor. Cero reescritura.

Esa es la razón por la que OpenAI, Google y Microsoft lo adoptaron en meses. No es filantropía. Cada uno quiere ganar el default host — el runtime que orquesta los MCP servers. El protocolo es la capa compartida debajo del foso.

La competición interesante ya no es entre modelos. Es entre los runtimes que orquestan capacidades.

El lado del host: validar que el protocolo es real

Este es un cliente MCP en TypeScript. Si tu servidor solo funciona en un host, no has construido un servidor MCP — has construido un plugin:

Conecta ese mismo cliente a Claude Desktop y a Cursor. Si el servidor se comporta idéntico en ambos, el contrato es real. Si solo funciona en uno, no es un servidor MCP, es un plugin disfrazado.

El transporte es una decisión de seguridad disfrazada

Aquí está el error más caro que he visto en el ecosistema: portar un servidor stdio a remoto sin cambiar la mentalidad de seguridad.

stdio mantiene el servidor como proceso hijo del host. Cero superficie de red. Es por eso que domina el uso local — Claude Desktop y Cursor lo usan por defecto. El servidor no escucha en ningún puerto. No hay nada que atacar desde fuera.

El momento en que expones un servidor por HTTP, heredas todo el catálogo: OAuth, CORS, prompt injection, escalada de privilegios.

El error típico: coger el servidor stdio de tu base de datos, envolverlo en streamable HTTP sin autenticación, y desplegarlo. *Acabas de exponer una shell sin login a tu PostgreSQL de producción. *

La regla es simple:

Local y stdio: sin autenticación extra. El proceso hijo es el límite de seguridad.
Remoto por HTTP: el spec pide OAuth. Implementa el flujo completo. Trata la ejecución de tools como superficie privilegiada — allow-lists, principio de menor privilegio, audit logs.

MCP local es seguro por arquitectura. MCP remoto es tan seguro como tu disciplina OAuth. Los dos no son lo mismo — y muchos lo aprenden después del incidente.

El Principio del Host Neutral

Si te llevas una sola cosa de este artículo, que sea esta. Lo llamo El Principio del Host Neutral:

Un servidor MCP que solo funciona en un host no es un servidor MCP. Es un plugin. La neutralidad de host es la propiedad que define el protocolo — si no la validas contra 2 o 3 hosts distintos, estás construyendo vendor lock-in disfrazado de estándar.

Cinco pasos para implementarlo:

Paso 1 — Identifica una capacidad que valga la pena exponer. Una base de datos, un repositorio, una API interna. Modelízala como servidor MCP, no como integración a medida. Empieza con una sola tool, no con un wrapper completo de SDK.

Paso 2 — Elige SDK. FastMCP para Python o el SDK oficial de TypeScript. Implementa una tool con esquemas de entrada explícitos. Ejecútala por stdio primero — es el transporte más simple y seguro para host local.

Paso 3 — Añade un resource y un prompt. No te quedes solo con tools. El server debe funcionar para acciones iniciadas por el modelo y para inyección de contexto controlada por el host. Ese es el salto de diseño.

Paso 4 — Conéctalo a 2-3 hosts distintos. Claude Desktop, Cursor, un cliente custom. Si solo vive en uno, tienes un plugin, no un MCP server.

Paso 5 — Resuelve auth y autorización ANTES de ir remoto. ¿Se queda local en stdio? No necesita auth extra. ¿Te mueves a streamable HTTP? Implementa el flujo OAuth del spec y trata la ejecución de tools como superficie privilegiada.

Las objeciones, respondidas con honestidad

"¿Por qué no usar OpenAPI/REST? Mi servicio ya tiene endpoints HTTP."

OpenAPI describe endpoints HTTP, pero no le da al modelo semántica de ciclo de vida. ¿Qué tools corren? ¿Qué contexto hay disponible? ¿Cómo recurren los prompts? MCP estandariza el contrato en la capa del agente, que es donde OpenAPI se queda corto. Y da igual qué tan ubicuo sea REST: el ecosistema ya se ha estandarizado en MCP como capa de intercambio para agentes.

"Darle tools a un LLM es una pesadilla de seguridad."

Es la objeción más legítima. Y las mitigaciones son duras: despliegues locales con stdio, scoping de menor privilegio por tool, allow-lists explícitas, OAuth para servidores remotos, audit logging. Siendo honestos: la prompt injection a través de fronteras de tools sigue siendo un problema de investigación no resuelto, no un problema resuelto. Construye asumiendo que el modelo puede ser manipulado.

"Otro estándar, otro ciclo de hype. Muerto en un año."

La refutación es la velocidad y amplitud de adopción. Varios vendors mayores dispararon soporte en cuestión de meses. Y lo clave: MCP no exige abandonar tus APIs existentes. Es una capa de adaptación delgada. El coste de adoptarlo es bajo aunque el propio protocolo evolucione.

Lo que MCP es de verdad

MCP no conecta modelos a datos. Conecta herramientas a cualquier modelo. Y eso es exactamente lo que hace que esté ganando.

No es el futuro de la integración. Es la tabla donde se sientan todos los agentes — y la pelea real es por quién preside la mesa.

Los que solo ven una API más bonita construirán plugins. Los que entienden que el runtime del agente es el nuevo campo de batalla construirán servidores neutrales que sobreviven a cualquier modelo, host o hype cycle.

Tú decides en qué bando estás. Pero decídelo rápido — el runtime ya está en juego.