Model Context Protocol (MCP) explicado con claridad — con ejemplo en n8n

Quien construye agentes de IA conoce el problema: para cada función de un servicio conectado hay que definir una herramienta propia. Buscar, crear, modificar y borrar una cita del calendario son ya cuatro piezas separadas, y eso para un único servicio. Con muchas conexiones, el esfuerzo de mantenimiento crece en consecuencia. El Model Context Protocol (MCP) sigue otro camino: estandariza cómo un modelo de lenguaje se comunica con un servicio y reduce drásticamente el número de piezas necesarias. Este artículo resume el concepto y un ejemplo práctico concreto con n8n.

Qué resuelve MCP en realidad

La idea básica del Model Context Protocol está en su nombre: un modelo de lenguaje debe entender el contexto de una aplicación. En concreto: ¿qué sabe hacer esta aplicación?, ¿para qué sirve? y ¿cómo ejecuto acciones dentro de ella?

Clásicamente, al construir un agente se conecta cada herramienta por separado: cada función es una pieza propia. En Google Calendar, por ejemplo: una herramienta para buscar citas, otra para actualizarlas, otra para borrarlas y otra para crearlas. Cuatro funciones para un servicio. En agentes complejos con muchos servicios conectados, eso suma pronto decenas de piezas.

Servidor, cliente y el esquema unificado

MCP trabaja con dos roles:

• Servidor MCP: se coloca delante del servicio propiamente dicho (p. ej. Airbnb o Google Calendar) y describe cómo se puede interactuar con él.
• Cliente MCP: reside en el agente, consulta las funciones del servidor y las invoca.

En la implementación actual, por ejemplo en n8n, bastan dos pasos en lugar de muchas herramientas sueltas:

1. List Tools (listar): el agente pregunta al servidor qué funciones hay disponibles.
2. Execute Tool (ejecutar): el agente invoca una función concreta con los parámetros adecuados.

Lo decisivo es el esquema unificado. Sea cual sea el servicio que hay detrás, la respuesta a una consulta List Tools tiene siempre la misma estructura. Por cada función incluye el nombre, una descripción y un esquema con los parámetros permitidos. Los contenidos y los parámetros varían de un servicio a otro; la estructura permanece constante. Eso es exactamente lo que el protocolo fija y estandariza.

Un ejemplo con la herramienta de Airbnb

Si se pregunta al agente qué posibilidades ofrece la herramienta de Airbnb, él mismo obtiene la lista de funciones mediante el tool List Tools. Devuelve, entre otras:

• Airbnb Search: búsqueda de alojamientos con filtros y paginación: ubicación, fechas de entrada y salida, número de adultos, niños, bebés y mascotas, así como rango de precios.
• Airbnb Listing Details: información detallada de un alojamiento concreto a partir de su listing ID.

Al agente no hubo que indicarle nada: obtuvo por sí mismo las funciones disponibles, sus descripciones y el esquema de parámetros. En el esquema se ve, por ejemplo, un campo de texto location (ciudad, región, etc.), los campos de fecha de entrada y de salida, el número de adultos y el precio mínimo y máximo.

Si después se hace una petición concreta —por ejemplo, un alojamiento en Bangkok para seis personas por un máximo de 50 euros la noche—, el agente actúa en dos fases: primero llama a List Tools (no ha memorizado nada, porque no hay memoria activa), reconoce a partir del esquema los parámetros necesarios y ejecuta la búsqueda con Execute Tool. El resultado —por ejemplo, un alojamiento con tres camas por unos 35 euros la noche— llega de vuelta, y todo ello con solo dos herramientas añadidas. Si Airbnb ofreciera más funciones, por ejemplo para gestionar los anuncios propios, podrían representarse con ese mismo esquema sin definir piezas adicionales.

Así reproduce MCP en n8n

Los pasos siguientes muestran la configuración con el ejemplo de Airbnb. Sirve bien para probar porque no hace falta ninguna clave de API.

1. Definir la variable de entorno: ponga N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE en true. Eso permite a los community nodes acceder a las herramientas. En una instalación con Docker (p. ej. en un servidor de Hetzner) lo indica en la sección environment del archivo docker-compose y reinicia la instancia.
2. Crear el AI Agent: cree un AI Agent y asígnele un modelo (en el vídeo, GPT-4.1 Mini).
3. Instalar el community node: en Settings → Community Nodes instale el paquete n8n-nodes-mcp y confirme el aviso sobre instalar código no verificado procedente de fuentes públicas.
4. Añadir el MCP client tool: con el signo más junto a Tools, busque «MCP». Atención: no lo confunda con el MCP Client Tool propio de n8n; la variante de la comunidad se reconoce por el icono de caja y hoy es más completa.
5. Crear las credenciales: como tipo de conexión puede elegir entre Command Line, Server-Sent Events y HTTP Streamable. En el ejemplo se mantiene Command Line. Los valores correctos figuran en el repositorio del servidor MCP correspondiente, en la sección de instalación. Para Airbnb: command npx y los argumentos introducidos paso a paso: -y, el paquete @openbnb/mcp-server-airbnb y, opcionalmente, --ignore-robots-txt.

Nota sobre robots.txt: la opción --ignore-robots-txt ignora las reglas de acceso de un sitio web. Para una demostración es defendible; en entornos productivos debería respetar el robots.txt de cada servicio.

Configurar las dos operaciones

A continuación necesita dos MCP client tools con operaciones distintas:

• List Tools: nombre la herramienta, por ejemplo, «Airbnb List Tools» e indique como descripción que sirve para recuperar todas las herramientas disponibles de Airbnb. Un clic de prueba (Execute Step) debería devolver la lista de funciones ya conocida, con nombre, descripción y esquema.
• Execute Tool: un segundo MCP client tool con la operación Execute Tool. Descripción: sirve para ejecutar herramientas de Airbnb, listables mediante el tool List Tools. El nombre de la herramienta se pasa como expression, de modo que el agente decida por sí mismo qué función invoca; los parámetros de la herramienta se dejan libres para que él los determine.

Tras ordenar y guardar, el agente puede probarse, por ejemplo otra vez con la consulta de Bangkok. Recupera la lista de funciones, se la devuelve al modelo, opta por la búsqueda y entrega alojamientos adecuados. Exactamente el comportamiento de la parte conceptual, ahora en el propio workflow.

Más allá de n8n — y una palabra sobre seguridad

MCP no se limita a las plataformas de automatización. También aplicaciones de escritorio como Claude Desktop pueden conectarse a servidores MCP. Así se pueden delegar tareas desde el chat a programas instalados localmente; un ejemplo muy citado es el control del software 3D Blender vía MCP, en el que una persona sin conocimientos de Blender genera renders. El servidor MCP se ejecuta localmente, mientras que el modelo de lenguaje sigue funcionando a través del servicio en la nube.

Con todo el entusiasmo, conviene recordar: MCP es un desarrollo joven. Ya existen reservas de seguridad y se han encontrado vulnerabilidades. Precisamente en entornos productivos hay que tomar la tecnología con cautela: vale la pena seguir su evolución antes de apoyar en ella procesos críticos.

Conclusión

El Model Context Protocol es un enfoque pragmático de estandarización: a través de un servidor MCP, un modelo de lenguaje aprende por sí mismo qué sabe hacer un servicio y cómo se le habla, en lugar de predefinir cada función una a una. Para agentes de IA complejos eso significa bastantes menos piezas y menos mantenimiento; en el ejemplo de n8n bastan dos pasos: listar y ejecutar. El enfoque convence, pero todavía es joven. Quien lo pruebe debería empezar por servicios no críticos y, en entornos productivos, tomarse en serio las cuestiones de seguridad abiertas.

Fuente: Model Context Protocol (MCP): Erklärung & n8n Tutorial (Deutsch) — canal de YouTube Philip Thomas (en alemán).