Qué es MCP: el Model Context Protocol explicado

Un modelo de lenguaje es tan útil como la información y las herramientas a las que puede llegar. De serie, un modelo no puede leer tu calendario, consultar tu base de datos ni crear una tarea en tu gestor de proyectos. El Model Context Protocol (MCP) es el estándar abierto que se ha convertido en la forma habitual de dar ese acceso a las aplicaciones de IA.

El problema que resuelve

Antes de MCP, cada aplicación de IA tenía que construir su propia integración con cada servicio: un conector de Slack para la app A, otro distinto para la app B, y así sucesivamente. Con muchas apps y muchos servicios, eso supone mucho trabajo duplicado e incoherente.

MCP define un idioma común. Un servicio implementa un servidor MCP una sola vez y cualquier aplicación compatible puede usarlo. La documentación oficial lo compara con un puerto USB-C para aplicaciones de IA: un conector estándar en lugar de un cajón lleno de cables distintos.

Un poco de historia

Anthropic publicó MCP como protocolo de código abierto en noviembre de 2024. Otras empresas de IA y herramientas para desarrolladores lo adoptaron rápido. En diciembre de 2025 Anthropic lo donó a la Agentic AI Foundation, un fondo de la Linux Foundation cofundado con Block y OpenAI, de modo que el protocolo tiene ahora una gobernanza neutral. Sus responsables siguen decidiendo la dirección técnica con aportaciones de la comunidad.

Cómo funciona: hosts, clientes y servidores

En MCP participan tres piezas:

• Host: la aplicación de IA que usas, por ejemplo Claude, ChatGPT, Visual Studio Code o Cursor.
• Cliente: un componente dentro del host que mantiene la conexión con un servidor. El host crea un cliente por cada servidor al que se conecta.
• Servidor: un programa que aporta contexto y capacidades: un servidor de GitHub, de archivos, de una base de datos.

Los servidores pueden ser locales, ejecutándose en tu ordenador y comunicándose con el host por la entrada y salida estándar (stdio), o remotos, en internet y accesibles por Streamable HTTP, normalmente con inicio de sesión OAuth.

Qué puede ofrecer un servidor

Los servidores ofrecen tres piezas básicas, llamadas primitivas:

• Herramientas (tools): acciones que el modelo puede pedir, como «crear incidencia», «buscar archivos» o «ejecutar consulta». Cada herramienta tiene un nombre, una descripción y un esquema de sus parámetros.
• Recursos (resources): datos que la aplicación puede leer como contexto, como el contenido de un archivo o el esquema de una base de datos.
• Prompts: plantillas reutilizables para interacciones habituales.

Además, un servidor puede pedir información al usuario cuando la necesita —por ejemplo, que confirme una acción— mediante una función llamada elicitation.

Cuando chateas, el host reúne las herramientas de todos los servidores conectados y se las ofrece al modelo. Si el modelo decide que una herramienta le ayudaría, la pide; el host llama al servidor, le devuelve el resultado y la conversación sigue. Por debajo, los mensajes usan el formato JSON-RPC 2.0.

Qué cambió en la especificación 2026-07-28

MCP evoluciona mediante versiones fechadas de la especificación. La revisión 2026-07-28, la vigente al escribir esta guía, trajo cambios importantes:

• Sin estado por diseño. Se eliminaron el antiguo saludo de inicialización y las sesiones del protocolo. Cada petición lleva su versión y sus capacidades, y los servidores anuncian lo que admiten con una nueva petición server/discover. Así es más fácil escalar los servidores remotos.
• Peticiones de varias idas y vueltas. Cuando un servidor necesita más información para terminar una petición (como una respuesta del usuario), devuelve un resultado de «falta información» y el cliente reintenta con la respuesta.
• Suscripciones. Los avisos de cambios, como «ha cambiado la lista de herramientas», llegan ahora por un único canal que hay que activar.
• Funciones obsoletas. Roots, Sampling (que el servidor pida respuestas al modelo del cliente) y Logging pasan a estar obsoletas, con al menos doce meses antes de retirarse.
• Extensiones. Las funciones opcionales viven fuera del núcleo, como Tasks para trabajos largos y MCP Apps para interfaces interactivas dentro de la conversación.

No necesitas estos detalles para usar conectores, pero explican por qué algunos servidores y clientes se comportan distinto según las versiones que admiten.

MCP, function calling y skills

Son tres ideas relacionadas que se confunden a menudo:

• Function calling es la capacidad del modelo: puede pedir que se ejecute una herramienta.
• MCP es la forma estándar de empaquetar y compartir herramientas y datos para que muchas apps los usen.
• Las skills son instrucciones empaquetadas que enseñan a un asistente cómo hacer una tarea de una forma concreta. Los conectores dan acceso a apps y datos; las skills enseñan el método. A menudo se usan juntos.

Seguridad: qué vigilar

Un servidor MCP actúa con los permisos que le das, así que instalar uno es como instalar un programa:

• Usa servidores de editores de confianza: los oficiales del propio servicio o proyectos de código abierto bien mantenidos.
• Concede el mínimo acceso necesario, por ejemplo tokens de solo lectura cuando se pueda.
• Ten cuidado con los servidores que traen contenido de fuera (webs, correos, incidencias): ese contenido puede esconder intentos de inyección de prompts.
• Mantén activadas las peticiones de aprobación para acciones que escriben, envían o borran.
• Repasa de vez en cuando qué conectores tienes activos y quita los que ya no uses.

¿Quieres probarlo? Sigue nuestra guía paso a paso para instalar un servidor MCP.