MCP (Model Context Protocol): cómo se conectan los agentes de IA a datos y herramientas

El problema de las N × M integraciones

Un agente de inteligencia artificial vale lo que valen sus herramientas. Sin acceso a tu CRM, a tu base de datos o a tu repositorio, es un modelo que opina.

Hasta hace poco, conectar cada herramienta era trabajo artesanal. Si tienes N aplicaciones con IA (un chat, un IDE, un agente interno) y M sistemas a los que conectarlas (GitHub, Postgres, Slack, tu API), acabas escribiendo N × M integraciones, cada una con su forma de describir las herramientas, de pasar argumentos y de autenticarse. Cambias de proveedor de modelo y reescribes la mitad.

Un protocolo común convierte ese N × M en N + M: cada aplicación implementa el protocolo una vez como cliente, cada sistema lo implementa una vez como servidor, y cualquiera habla con cualquiera.

Qué es MCP

El Model Context Protocol es un estándar abierto que define cómo una aplicación con un modelo de lenguaje descubre qué herramientas y datos tiene disponibles, y cómo los usa. Lo publicó Anthropic en noviembre de 2024; en diciembre de 2025 lo cedió a la Agentic AI Foundation, bajo el paraguas de la Linux Foundation, para que ninguna empresa sea dueña del estándar. Hoy lo soportan los productos de los grandes proveedores de modelos y la mayoría de editores de código con IA.

La analogía oficial es la del USB-C para la IA: un conector único para que cualquier aplicación enchufe cualquier fuente de datos o herramienta. Es una buena analogía, con una trampa que veremos al final.

La inspiración técnica declarada es otra, y es más precisa: el Language Server Protocol, el estándar que permitió que cualquier editor tuviera autocompletado para cualquier lenguaje sin que cada editor implementara cada lenguaje. Mismo problema N × M, misma solución.

Las tres piezas: host, cliente y servidor

┌──────────────── host (IDE, app de chat, tu agente) ────────────────┐
│  modelo                                                            │
│    │                                                               │
│  cliente MCP ──── cliente MCP ──── cliente MCP                     │
└──────┼─────────────────┼─────────────────┼─────────────────────────┘
       │ stdio           │ HTTP            │ HTTP
  servidor MCP      servidor MCP      servidor MCP
  (archivos)        (tu base de datos)  (web scraping)

Host: la aplicación donde vive el modelo. Decide qué servidores se conectan y pide permiso al usuario.
Cliente: dentro del host, una conexión por servidor.
Servidor: un programa, normalmente pequeño, que envuelve un sistema (una API, una base de datos, el sistema de archivos) y lo expone en el formato del protocolo.

Por debajo, los mensajes son JSON-RPC 2.0. El transporte es la entrada estándar del proceso para servidores locales, o HTTP para servidores remotos, que además se autentican con OAuth.

Lo que un servidor ofrece

Un servidor MCP puede exponer tres tipos de cosas, y la diferencia entre ellas es quién decide usarlas:

Primitiva	Qué es	Quién la activa
Herramientas (tools)	Acciones con efectos: consultar, crear, enviar	El modelo, cuando lo cree necesario
Recursos (resources)	Datos para leer: un archivo, un registro, un esquema	La aplicación, que decide qué meter en el contexto
Prompts	Plantillas de instrucciones reutilizables	El usuario, que las elige

En el sentido contrario, el servidor también puede pedirle cosas al cliente: que el modelo del host genere un texto (sampling) o que el usuario aporte un dato que falta (elicitation).

Así se ve el momento clave, cuando el cliente pregunta qué herramientas hay:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "buscar_facturas",
        "description": "Busca facturas de un cliente por su identificador fiscal. Devuelve como máximo 20, de la más reciente a la más antigua.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "nif": { "type": "string", "description": "Identificador fiscal del cliente" },
            "desde": { "type": "string", "format": "date" }
          },
          "required": ["nif"]
        }
      }
    ]
  }
}

El host le pasa al modelo el nombre, la descripción y el esquema. Cuando el modelo decide usarla, el cliente envía un tools/call con los argumentos, el servidor ejecuta y devuelve el resultado, y ese resultado entra en el contexto del siguiente paso del bucle.

MCP frente a las APIs propietarias

El título "MCP contra las APIs" es engañoso, y conviene deshacerlo porque genera malas decisiones:

MCP no sustituye a tu API. Un servidor MCP casi siempre envuelve una API que ya existe. La API sigue siendo el contrato con tu sistema; MCP es el contrato con el agente.
MCP no sustituye al function calling. El function calling de cada proveedor es cómo el modelo expresa "quiero llamar a esto con estos argumentos". MCP es cómo la aplicación descubre qué se puede llamar y ejecuta la llamada. Son capas distintas que trabajan juntas.
Lo que sí sustituye es la capa de pegamento: el código que cada equipo escribía para traducir entre el formato de herramientas de un proveedor de modelos y cada API.

El efecto práctico es la separación entre la capa del modelo y la capa de infraestructura. Cambias de modelo y tus servidores MCP siguen sirviendo. Añades un servidor y todas tus aplicaciones lo ven. Es lo mismo que pasó con las bases de datos cuando apareció un estándar para hablarles: la aplicación dejó de estar casada con el motor.

MCP y RAG: empujar contexto o dejar que el modelo lo pida

Aquí está el cambio más profundo, y el que menos se explica.

En RAG clásico, tu código empuja el contexto: antes de llamar al modelo, buscas en la base vectorial los fragmentos parecidos a la pregunta y los pegas en el prompt. El modelo no elige qué leer; lee lo que le das.

Con MCP, el modelo puede tirar del contexto: la búsqueda vectorial se expone como una herramienta, y es el modelo quien decide si buscar, con qué consulta, y si lo que encontró basta o hay que reformular y buscar otra vez. Es lo que se ha llamado RAG agéntico, y varios proveedores de bases vectoriales ya publican su propio servidor MCP para eso.

Las dos formas conviven, y las primitivas de MCP las reflejan:

	RAG clásico	Recursos MCP	Herramientas MCP
Quién decide qué entra en el contexto	Tu código	La aplicación	El modelo
Cuántas búsquedas	Una, fija	Las que la aplicación haga	Las que el modelo quiera
Previsibilidad	Alta	Alta	Baja
Se adapta a preguntas difíciles	Poco	Poco	Mucho

Elegir entre ellas es la misma decisión que en los patrones de agentes: cuánta autonomía compensa.

Cómo cambia el desarrollo de software

Tres consecuencias que ya se ven:

Las herramientas de desarrollo se montan sobre MCP. Los editores con IA y los agentes de programación son clientes MCP: les conectas un servidor de tu base de datos, de tu gestor de incidencias o de documentación, y el agente lo usa sin que nadie del editor haya escrito esa integración.
Los servicios publican su servidor MCP como publicaban su SDK. Firecrawl, por ejemplo, ofrece el suyo: cualquier agente que hable MCP puede leer y rastrear páginas web sin una línea de código de integración. Un producto sin servidor MCP empieza a ser, para los agentes, un producto sin API.
La documentación pasa a ser parte de la interfaz. El modelo decide qué herramienta usar leyendo su descripción. Una descripción ambigua es una herramienta que se usa mal. Una descripción de herramienta es un prompt, y se escribe con el mismo cuidado.

Lo que la analogía del USB esconde

Un USB-C negocia qué puede hacer cada extremo y no hay nada más que discutir. MCP no llega tan lejos, y hay tres huecos que conviene conocer antes de conectar veinte servidores:

Cada herramienta cuesta contexto. Las definiciones de todas las herramientas conectadas se envían al modelo. Veinte servidores con diez herramientas cada uno son miles de tokens antes de que el usuario escriba nada, en cada vuelta del bucle, y un modelo con doscientas herramientas elige peor que uno con diez. Conecta lo que la tarea necesita, no lo que existe.
Las descripciones son texto que el modelo obedece. Un servidor malicioso, o el contenido que devuelve una herramienta legítima, puede incluir instrucciones que el modelo tome como órdenes. Simon Willison llamó a la combinación peligrosa la trifecta letal: acceso a datos privados, exposición a contenido no confiable y capacidad de comunicar hacia fuera. Un agente con las tres puede ser convencido de sacar tus datos. Instala servidores como instalarías dependencias: de fuentes conocidas y con permisos mínimos.
El protocolo estandariza el cable, no el significado. El inputSchema es JSON Schema: dice que desde es una cadena con formato fecha, no qué zona horaria ni si es inclusiva. Es exactamente el problema de JSON como caverna de Platón: MCP hace que las sombras lleguen a todas partes con el mismo formato. Que signifiquen lo mismo en ambos extremos sigue siendo trabajo tuyo.

Pruébalo: revisa una descripción de herramienta

Si una descripción de herramienta es un prompt, se puede revisar como un prompt. Pega la descripción de una herramienta tuya, o deja esta, que es deliberadamente mala, y mira qué le falta para que un modelo la use bien.

Para llevarte

MCP convierte N × M integraciones en N + M: un cliente por aplicación, un servidor por sistema.
No compite con tu API ni con el function calling: los envuelve y los conecta.
Traslada una decisión de tu código al modelo: con MCP, el modelo puede pedir el contexto en lugar de recibirlo. Es más potente y menos previsible.
Cada herramienta conectada consume contexto y amplía la superficie de ataque. Y el protocolo transporta la forma de los datos, no su significado.