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

> MCP es el estándar abierto con el que un agente de IA descubre y usa herramientas sin una integración a medida por cada una. Qué es, cómo funciona por dentro, qué cambia respecto a RAG y a las APIs propietarias, y lo que la analogía del USB esconde.

- Fuente canónica: https://www.ricardovelit.com/blog/p/mcp-model-context-protocol
- Nivel: intermedio · Lectura: 7 min · Publicado: 2026-09-23
- Etiquetas: agentes, mcp, herramientas, rag, protocolos
- Conviene leer antes: [agentes-de-inteligencia-artificial](https://www.ricardovelit.com/blog/p/agentes-de-inteligencia-artificial.md)
- Relacionados: [rag-recuperacion-aumentada](https://www.ricardovelit.com/blog/p/rag-recuperacion-aumentada.md), [bases-de-datos-vectoriales](https://www.ricardovelit.com/blog/p/bases-de-datos-vectoriales.md), [tokens-y-tokenizacion](https://www.ricardovelit.com/blog/p/tokens-y-tokenizacion.md)
- Contiene componentes interactivos que solo funcionan en la versión web.

---
## 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

```text
┌──────────────── 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:

```json
{
  "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](/p/rag-recuperacion-aumentada) clásico, **tu código empuja el contexto**: antes de
llamar al modelo, buscas en la [base vectorial](/p/bases-de-datos-vectoriales) 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](/p/patrones-de-diseno-de-agentes-de-ia): cuánta autonomía
compensa.

## Cómo cambia el desarrollo de software

Tres consecuencias que ya se ven:

1. **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.
2. **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.
3. **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](/p/tokens-y-tokenizacion) 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](/p/json-es-la-caverna-de-platon): 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.

> **[Componente interactivo: PromptPlayground]** — playground de prompts: ejecuta un prompt contra un modelo real o simulado. Solo en la versión web: https://www.ricardovelit.com/blog/p/mcp-model-context-protocol

## 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.