Qué es MCP (Model Context Protocol): servidores, clientes, herramientas y recursos

El Model Context Protocol (MCP) es un estándar abierto que permite a un asistente de IA usar herramientas y datos externos a través de una interfaz común, en lugar de una integración distinta para cada aplicación. Un servidor MCP expone capacidades (herramientas, recursos, plantillas de prompts) y el cliente MCP que llevan Claude, Cursor, ChatGPT u otros asistentes las descubre y las invoca cuando una pregunta lo requiere. Para una empresa, esto significa conectar una base de conocimiento o un sistema interno una sola vez y aprovecharlo en todos los asistentes compatibles.

Qué es MCP y qué problema resuelve

Un modelo de lenguaje razona muy bien sobre texto, pero por sí solo no ve su intranet, su ERP ni la última modificación de una normativa autonómica. Durante años, cada asistente tuvo su propio sistema de extensiones: una empresa de software que quería estar presente en tres asistentes tenía que desarrollar y mantener tres conectores, y el departamento de TI tenía que revisar tres modelos de seguridad distintos.

MCP sustituye todo eso por un contrato único. La especificación se publicó en abierto a finales de 2024 y está documentada en modelcontextprotocol.io. Se suele comparar con un puerto USB-C para la IA: el asistente tiene una sola toma y cualquier cosa que hable el protocolo encaja en ella. Usted desarrolla un servidor MCP una vez y funciona con todos los clientes compatibles.

Técnicamente, los mensajes siguen el formato JSON-RPC 2.0: el cliente envía un nombre de método con sus parámetros y el servidor devuelve un resultado o un error. Lo que aporta MCP es un vocabulario compartido (listar herramientas, llamarlas, leer recursos) y un saludo inicial en el que cada parte declara lo que sabe hacer.

Anfitrión, cliente y servidor: la arquitectura de MCP

La especificación distingue tres papeles. Tenerlos claros facilita entender cualquier tutorial.

• Anfitrión (host): la aplicación con la que trabaja el usuario, como una aplicación de chat, un editor de código como Cursor o un agente de terminal. Controla el modelo, la conversación y las solicitudes de permiso.
• Cliente: un componente dentro del anfitrión que mantiene una conexión con un único servidor. Un anfitrión conectado a cinco servidores ejecuta cinco clientes.
• Servidor: el programa que expone capacidades. Puede ejecutarse en local (ficheros, git, una base de datos del equipo) o en remoto como servicio web (un SaaS, un buscador documental, una API interna).

Transporte local o remoto

MCP define dos transportes estándar. Con stdio, el anfitrión arranca el servidor como subproceso y se comunica con él por la entrada y la salida estándar: es lo habitual para herramientas locales. Con Streamable HTTP, el servidor es una dirección HTTPS a la que se llama con una clave API o un token OAuth en las cabeceras. Para una pyme, este segundo modo es el más práctico: basta con una URL y una clave, sin instalar nada en cada ordenador.

Cómo transcurre una sesión

1. Inicialización: el cliente se conecta y ambas partes intercambian la versión del protocolo y sus capacidades.
2. Descubrimiento: el cliente pide la lista de herramientas, cada una con nombre, descripción y un esquema JSON de sus parámetros.
3. Decisión: ante la petición del usuario, el modelo lee esas descripciones y valora si alguna herramienta le ayuda.
4. Llamada: el cliente envía la llamada con sus argumentos; el servidor la ejecuta y devuelve un contenido, normalmente texto.
5. Respuesta: el modelo redacta su respuesta a partir de ese resultado y, si está bien diseñado, cita la fuente.

Herramientas, recursos y prompts: qué ofrece un servidor MCP

Un servidor puede exponer tres tipos de capacidades. Su diferencia principal es quién decide usarlas.

El protocolo también permite que el cliente ofrezca funciones al servidor, como pedir una aclaración al usuario. Aun así, en la práctica las herramientas concentran casi todo el uso real: permiten al modelo ir a buscar la información por su cuenta mientras el anfitrión conserva el control de las autorizaciones.

Cómo Claude, Cursor y ChatGPT consultan bases de conocimiento con MCP

Un asistente generalista no conoce sus procedimientos internos, sus tarifas del trimestre ni la redacción exacta de una norma recién modificada. Esa carencia es justo lo que cubre la generación aumentada por recuperación (RAG): primero se buscan los pasajes adecuados en documentos fiables y después el modelo responde a partir de ellos. MCP es la forma más sencilla de poner una base RAG al alcance de los asistentes que su equipo ya utiliza.

Un ejemplo concreto es Kopik. Su servidor MCP, en https://kopik.fr/api/mcp, usa el transporte Streamable HTTP y expone tres herramientas: list_bases (gratuita, lista las bases públicas del catálogo, con filtro opcional por tema o palabras), ask_base (devuelve una respuesta redactada y los pasajes de origen numerados) y search_base (devuelve solo los pasajes, al mismo precio, para agentes que prefieren razonar por sí mismos). Un intercambio típico:

1. En Cursor, una usuaria pregunta: «¿Qué garantías exige el RGPD para transferir datos personales a un proveedor fuera de la UE?»
2. El modelo detecta una herramienta adecuada y llama a ask_base sobre una base como GDPR & International Data Transfers: Official EU Texts.
3. El servidor recupera los pasajes pertinentes de los documentos indexados y devuelve una respuesta basada en ellos, con citas numeradas.
4. El modelo redacta su respuesta y remite a los pasajes citados, que la usuaria puede comprobar.

El mismo servidor funciona en Claude Code, Cursor, ChatGPT y otros clientes MCP. En Claude Code basta un comando: claude mcp add --transport http kopik https://kopik.fr/api/mcp --header "Authorization: Bearer kpk_…". En Cursor se añade una entrada «kopik» bajo mcpServers en el fichero .cursor/mcp.json, con la URL y la cabecera Authorization. Para conectar una sola base se usa su propia dirección (https://kopik.fr/api/mcp?base= seguido de su identificador); en zsh, ponga entre comillas cualquier URL con signo de interrogación.

RGPD y seguridad: qué revisar antes de conectar un servidor

Cada servidor MCP pasa a formar parte de sus flujos de datos. Si por él circulan datos personales, se aplica el RGPD con todas sus obligaciones, y las guías de la AEPD sobre inteligencia artificial son un buen punto de partida. El Reglamento europeo de IA (AI Act) añade, según el uso, requisitos de transparencia y gestión de riesgos.

• Documentar los flujos: qué servidor recibe qué información. Actualice el registro de actividades de tratamiento y, si el riesgo es alto, la evaluación de impacto; firme un contrato de encargado del tratamiento cuando corresponda.
• Limitar permisos: una clave API por servidor y por uso, con el acceso mínimo, revocada al terminar el proyecto.
• Prevenir la inyección de instrucciones: el contenido devuelto por un servidor puede incluir texto que intenta dirigir al modelo. Prefiera servidores que lo marquen como no fiable y mantenga la aprobación humana para herramientas que escriben, envían o borran.
• Poner techo al gasto: en herramientas de pago, fije un límite; en Kopik, el argumento maxPriceCents rechaza la llamada sin coste si la base es más cara.
• Respetar los límites: los servidores remotos limitan las peticiones por minuto y por día; sus agentes deben esperar en lugar de reintentar en bucle.

¿MCP o API REST?

No hay que elegir: se complementan. Una API REST encaja con código determinista, como tareas programadas, formularios o integraciones que controlan sus desarrolladores de principio a fin. MCP encaja cuando es un modelo quien decide, en mitad de la conversación, qué capacidad necesita. Por eso muchos servicios ofrecen ambas. Regla práctica: si la pregunta la hace una persona en un asistente, MCP; si la hace un programa, la API. Y si sus documentos aún no están en ninguna base, puede crear una base de conocimiento gratis a partir de PDF o Word.