Qué resuelve realmente MCP: de N × M integraciones a N + M

La pregunta detrás del bombo

Un equipo que lanza soporte para MCP (un servidor con 16 herramientas y un cliente que se conecta a otros servidores MCP) acabará oyendo la objeción más afilada desde dentro de casa: si MCP solo llama a API y devuelve datos, ¿para qué molestarse? Las API REST ya existen.

Es una pregunta razonable, y la mayoría de las explicaciones de MCP tropiezan porque empiezan por el protocolo y no por el problema. Así que empecemos por el problema.

Para qué problema existe MCP

Imagina a una responsable que le pregunta a un asistente de IA: ¿qué solicitudes de compra están esperando mi aprobación? El sistema de compras tiene la respuesta y probablemente una API REST delante. Entonces, ¿qué falta? Hay cuatro caminos habituales, y cada uno tiene su pega:

1. Copiar los registros en la ventana del chat. Funciona una vez, a mano, y la copia empieza a envejecer al instante.
2. Integrar un chatbot dentro de la propia aplicación de compras. Es más cómodo, pero la IA queda encerrada en esa aplicación y la integración te toca mantenerla para siempre.
3. Pegar la documentación de la API y confiar en que el modelo elija el endpoint correcto. Puede funcionar, aunque se rompe con facilidad.
4. Escribir una integración dedicada para cada asistente que se use en la empresa.

El último camino se complica enseguida. Una empresa con 10 sistemas internos y 5 asistentes puede necesitar hasta 10 × 5 = 50 integraciones distintas, cada una con su código de autenticación, sus rarezas y su mantenimiento. MCP se diseñó precisamente para eliminar esa multiplicación.

De N × M a N + M

En lugar de conectar cada cliente de IA con cada sistema, cada sistema describe sus capacidades una vez mediante un protocolo estándar, y cada cliente de IA implementa ese protocolo una vez. Sin MCP, cada combinación necesita su propia integración:

Without MCP: every pair needs its own integration

System A ──── AI Client 1
System A ──── AI Client 2
System B ──── AI Client 1
System B ──── AI Client 2N × M integrations

Con MCP, cada lado se construye una sola vez:

With MCP: build once on each side

System A ──┐             ┌── AI Client 1
System B ──┼──── MCP ────┼── AI Client 2
System C ──┘             └── AI Client 3N + M implementations

Para diez sistemas y cinco asistentes, la cifra baja de 50 a 15 implementaciones. En una línea: MCP permite que un asistente averigüe qué ofrece un sistema y lo invoque usando una convención compartida.

Hay tres ideas que hacen que todo encaje.

1. Dentro del servidor MCP no hay ninguna IA

Este es probablemente el malentendido más común. La gente imagina una cadena así:

User → AI → MCP Server → API → AI → Answer

con un segundo modelo razonando al otro lado. No existe nada parecido. El servidor es código normal y corriente que nunca llama a un LLM. En la práctica, lo que ocurre se parece más a esto:

User
 ↓
LLM            decides which tool it needs
 ↓
MCP Client     sends the call
 ↓
MCP Server     executes it
 ↓
Your API / business logic
 ↓
Structured data
 ↓
LLM            interprets the result
 ↓
Answer

El servidor son las manos y el modelo es el cerebro.

2. «Ya tenemos API REST»

Cierto, y la API nunca fue lo que faltaba. Toma una aplicación de compras con este endpoint:

GET /api/v1/rtps?view=inbox&page=0

Una persona lee la documentación y lo entiende. Un modelo tiene que deducir, mientras se ejecuta, qué representa el endpoint, cuándo se aplica y qué parámetros enviar, y nadie ha escrito el código de unión que se lo explique.

Lo que aporta MCP es el descubrimiento. Un cliente puede preguntarle a un servidor qué sabe hacer y recibir una lista de capacidades:

list_my_approvals
get_purchase_request
search_suppliers
get_purchase_order
create_rfq

Cada entrada lleva una descripción y un esquema de entrada. La primera herramienta le llega al modelo más o menos así:

{
  "name": "list_my_approvals",
  "description": "List purchase requests waiting for the current user's approval.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "page": { "type": "integer", "description": "Zero-based page number" }
    }
  }
}

Pon GET /api/v1/rtps?view=inbox&page=0 junto a list_my_approvals. La URL nombra una ruta, mientras que el nombre de la herramienta expresa una capacidad con palabras sobre las que un modelo puede razonar. Ese es el hueco que llena MCP.

(Los servidores también pueden ofrecer recursos y prompts reutilizables, pero las herramientas son el punto de partida habitual y el tema de este artículo.)

3. Lo interesante es la composición

Aquí MCP pasa a ser algo más que un envoltorio de una API. Conecta tres servidores a un mismo asistente:

• Un servidor de monitorización con get_system_health y get_recent_incidents
• Un servidor de conocimiento que ofrece get_document, search_documents y find_certificate
• Un servidor de compras cuyas herramientas son get_purchase_order, get_purchase_request y list_my_approvals

Después hazle al asistente una pregunta compuesta: enumera las solicitudes de compra pendientes y marca las que no tengan certificados de respaldo. El modelo llama a las herramientas de compras, consulta al servidor de conocimiento los certificados de cada solicitud, combina los resultados y responde una sola vez. Ningún servidor sabe de los demás, y no pasa nada.

Así que es el propio modelo el que integra. Compáralo con un único chatbot sobredimensionado conectado a fuego a cada backend. Aquí, un sistema nuevo llega como un servidor más y el asistente no se toca.

El modelo como capa de integración

La integración tradicional es así:

System A
   ↕
Integration Layer
   ↕
System B

Con IA agéntica, el panorama pasa a ser:

               AI Model
             /    |    \
            /     |     \
     MCP Server  MCP Server  MCP Server
          |          |          |
      Procurement  Knowledge  Monitoring

El modelo decide qué capacidad necesita, algo fundamentalmente distinto de construir una sola capa de integración que entienda todos los sistemas.

El paralelismo con LSP

Los desarrolladores ya han visto esta forma en el Language Server Protocol. Antes, cada editor escribía su propio autocompletado, «ir a la definición» y resaltado de errores para cada lenguaje: el mismo enredo N × M. Con LSP, un lenguaje ofrece esas funciones una vez, como servidor de lenguaje, y cualquier editor que hable el protocolo las obtiene. MCP toma prestado de LSP abiertamente.

Casi nadie pregunta para qué necesita Java LSP si ya tiene compilador. El compilador nunca fue el objetivo. Del mismo modo, tu API expresa lo que el sistema puede hacer, mientras que MCP expresa cómo un cliente de IA descubre esas capacidades y las invoca.

Así que la comparación no es REST contra MCP. Es REST por debajo y MCP por encima para la interoperabilidad con IA.

Lo que MCP deja sin resolver

El bombo suele saltarse esta parte.

Un modelo no se vuelve más listo gracias a MCP. Las descripciones de las herramientas funcionan como prompts, así que una descripción descuidada produce llamadas descuidadas.

Tampoco se encarga nadie de la seguridad por ti. Publicar search_suppliers apenas tiene riesgo, porque solo consulta, pero publicar approve_purchase_order entrega un control financiero. Prevé autenticación, autorización, mínimo privilegio, registros de auditoría y una confirmación explícita antes de cualquier cambio de estado.

Recuerda también que todo lo que devuelve una herramienta va directo al contexto del modelo. Un documento obtenido puede incluir instrucciones pensadas para torcer la siguiente llamada a una herramienta, así que trata la salida de las herramientas como entrada no confiable. MCP abre la puerta a las capacidades y no dice nada sobre si es seguro cruzarla.

¿Necesitas MCP en realidad?

Tener una API no es el criterio adecuado. El mejor es si un modelo elige qué capacidad invocar desde un cliente de IA que no controlas.

Si la respuesta es no, olvídate de MCP; las llamadas a API simples o el function calling de tu framework son más sencillos. Si es sí, la interoperabilidad es tu problema, y puedes abordarla con plugins a medida, protocolos propietarios e integraciones por cliente, o adoptando un estándar. La decisión se reduce a eso.

Lo que demuestra un servidor de 16 herramientas

Una vez que existe un servidor con 16 herramientas, lo interesante no es que la IA del propio equipo pueda llamar a su propia API, porque eso ya era posible. Lo interesante es que otro cliente de IA puede descubrir las capacidades del sistema sin que nadie haya construido una integración para él.

Esa es la recompensa. La API contiene lo que se puede hacer; MCP es cómo un asistente averigua lo que es posible y lo ejecuta. Con esa distinción en mente, MCP parece menos una palabra de moda y más una pieza de fontanería.