Cada vez que un equipo quiere que un modelo de lenguaje haga algo útil de verdad (consultar una base de datos, leer un fichero, disparar una acción en un CRM) se topa con el mismo problema: hay que escribir una integración a medida. Si mañana cambias de modelo, hay que rehacerla. Si el modelo tiene que hablar con cinco sistemas distintos, son cinco integraciones distintas, cada una con su lógica, su autenticación y su formato. Model Context Protocol (MCP) nace en noviembre de 2023 de la mano de Anthropic precisamente para acabar con esa fragmentación.
Dejar de reinventar cada conexión
Antes de MCP, cada proveedor de modelos (OpenAI, Anthropic, Google) tenía su propio mecanismo de "function calling" o "tool use", con su propio formato de definición de herramientas. Si construías un agente que necesitaba acceder a Google Drive, Slack y una base de datos PostgreSQL, tenías que escribir tres integraciones distintas y, si cambiabas de modelo, revisarlas todas otra vez.
MCP propone un estándar abierto: un único protocolo que cualquier modelo puede hablar y al que cualquier sistema puede conectarse. La analogía más citada es acertada: MCP es al mundo de la IA lo que el Language Server Protocol (LSP) fue a los editores de código. Antes de LSP, cada editor tenía que implementar soporte para cada lenguaje de programación por separado. Después, bastaba con un servidor LSP por lenguaje y cualquier editor compatible podía usarlo. MCP hace lo mismo con las conexiones entre modelos y herramientas.
Arquitectura: hosts, clients y servers
MCP se organiza en tres piezas que conviene distinguir bien porque los nombres se prestan a confusión:
- •Host: la aplicación que el usuario final utiliza y que integra un modelo de IA. Puede ser Claude Desktop, un IDE como Cursor, o una aplicación propia construida sobre n8n.
- •Client: el componente dentro del host que mantiene una conexión uno-a-uno con un servidor MCP concreto. Un host puede tener varios clients activos a la vez, uno por cada servidor al que se conecta.
- •Server: el proceso que expone capacidades concretas —herramientas, datos, plantillas— siguiendo el estándar MCP. Puede correr en local (un script que lee ficheros del disco) o remoto (una API que consulta un ERP).
La comunicación entre client y server usa JSON-RPC 2.0 sobre distintos transportes: stdio para procesos locales, y HTTP con Server-Sent Events (o el más reciente Streamable HTTP) para servidores remotos. Gracias a esta separación, el mismo servidor MCP sirve tanto si el host está en el mismo ordenador como si está al otro lado de internet.
Los tres primitivos que expone un servidor
Un servidor MCP no ofrece "funcionalidades" genéricas, sino tres tipos de capacidades bien delimitadas:
- •Tools: funciones que el modelo puede invocar, con efectos secundarios. Por ejemplo, "crear una tarea en Jira" o "enviar un correo".
- •Resources: datos que el modelo puede leer para tener contexto, como el contenido de un fichero, el esquema de una tabla o los resultados de una consulta.
- •Prompts: plantillas reutilizables que el servidor ofrece para guiar interacciones concretas, pensadas para que el usuario las invoque explícitamente.
Esta separación importa porque cambia cómo se diseña la seguridad: las tools requieren normalmente confirmación humana antes de ejecutarse, mientras que los resources son de solo lectura y se pueden cargar sin fricción.
Un servidor MCP mínimo, en código
Para que quede claro que no es magia, así se ve un servidor MCP muy simple escrito en Python con el SDK oficial, que expone una única tool para consultar el estado de un pedido:
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("pedidos-server")
@mcp.tool()
def consultar_pedido(pedido_id: str) -> str:
"""Devuelve el estado de un pedido a partir de su identificador."""
estado = buscar_estado_en_bbdd(pedido_id)
return f"El pedido {pedido_id} está en estado: {estado}"
if __name__ == "__main__":
mcp.run(transport="stdio")Cualquier host compatible con MCP (Claude Desktop, un cliente propio o un nodo de n8n) puede arrancar este proceso, descubrir automáticamente que existe la tool consultar_pedido y ofrecérsela al modelo cuando la conversación lo requiera. No hace falta tocar el prompt del sistema a mano para describir la herramienta: el propio protocolo se encarga del descubrimiento.
Dónde encaja MCP en un proyecto real
En proyectos de automatización con n8n, MCP está ganando terreno como capa de conexión entre agentes y sistemas corporativos. En lugar de construir un nodo HTTP Request distinto para cada API, se despliega un servidor MCP delante del sistema (un ERP, un gestor documental, una base de datos) y el agente lo consume de forma uniforme. Esto simplifica especialmente los flujos donde el agente necesita decidir dinámicamente qué herramienta usar según la conversación, en lugar de seguir un flujo predefinido.
En el terreno de Liferay DXP, el patrón tiene sentido cuando se quiere dar a un agente de IA acceso controlado al contenido de un portal: exponer como resources las páginas y documentos indexados, y como tools acciones concretas como crear un ticket de soporte o actualizar un registro en un formulario dinámico. El servidor MCP actúa de intermediario que decide qué puede ver y qué puede tocar el modelo, sin exponer directamente la API REST completa de Liferay.
Otro caso frecuente es conectar un asistente interno con documentación técnica dispersa: repositorios de código, wikis y tickets de Jira, cada uno con su propio servidor MCP. El modelo pasa a tener una vista unificada sin que el equipo tenga que mantener tres integraciones distintas cuando cambie de proveedor de modelo.
Qué conviene tener en cuenta antes de adoptarlo
MCP es todavía un estándar joven y eso tiene consecuencias prácticas:
- •Seguridad de las tools: dar a un modelo acceso a una tool que escribe en producción exige pasar por confirmación humana o, como mínimo, límites estrictos de alcance. No todos los servidores MCP publicados en repositorios comunitarios están auditados.
- •Gestión de autenticación: conectar un servidor MCP remoto a sistemas corporativos implica resolver OAuth, tokens y rotación de credenciales, algo que el protocolo contempla pero que sigue exigiendo trabajo de infraestructura.
- •Madurez del ecosistema: aunque ya hay soporte en Claude Desktop, Cursor, VS Code y varios frameworks de agentes, no todos los proveedores de modelos han adoptado MCP de forma nativa, así que conviene comprobar la compatibilidad antes de diseñar la arquitectura alrededor de él.
MCP no sustituye el diseño cuidadoso de permisos y auditoría: estandariza el transporte, pero la responsabilidad de qué puede hacer un agente sigue siendo de quien construye el servidor.
Si vas a empezar, el camino más pragmático es levantar un servidor MCP local sobre un sistema que ya conozcas bien (un fichero de datos, una API interna) antes de intentar conectar un servidor remoto a producción. Una vez entendido el ciclo de descubrimiento de tools y resources, escalar a integraciones con Liferay, ERPs o flujos de n8n es cuestión de repetir el mismo patrón con las credenciales y los límites de acceso bien definidos desde el principio.