Qué es MCP (Model Context Protocol) y cómo funciona

El Model Context Protocol (MCP) es un estándar abierto que define cómo una aplicación de IA pide herramientas y datos a servicios externos. Lo creó Anthropic en noviembre de 2024, lo mantiene un grupo de trabajo abierto, y hoy lo implementan Claude, ChatGPT, Cursor, VS Code y buena parte del ecosistema de editores con IA.

La comparación que usa la propia especificación es la mejor forma de entenderlo: MCP es al contexto de los modelos lo que el Language Server Protocol es a los editores de código. Antes de LSP, cada editor escribía su propia integración para cada lenguaje. Después, un servidor de lenguaje sirve a cualquier editor. MCP hace lo mismo con las herramientas: escribes el servidor una vez y lo consume cualquier aplicación que hable el protocolo.

Qué problema resuelve

Sin un protocolo común, conectar un modelo a una herramienta es trabajo a medida. Cada aplicación inventa su formato de definición de funciones, su forma de pasar credenciales y su manera de devolver resultados. Si tienes tres herramientas y dos aplicaciones, escribes seis integraciones.

MCP convierte eso en una suma en vez de una multiplicación. Cada herramienta se expone una vez como servidor, cada aplicación implementa el protocolo una vez como cliente, y las dos partes se descubren en tiempo de ejecución. El modelo no conoce la implementación de la herramienta: solo lee su nombre, su descripción y sus parámetros.

Quién habla con quién: host, cliente y servidor

Aquí es donde casi todas las explicaciones se equivocan, porque hablan de "el modelo, el servidor y las herramientas". La arquitectura real tiene tres participantes y el modelo no es ninguno de ellos:

• Host: la aplicación de IA que inicia las conexiones. Claude Code, Cursor o ChatGPT son hosts. Es quien contiene al modelo, quien pide el consentimiento al usuario y quien decide qué se ejecuta.
• Cliente: el conector que vive dentro del host y mantiene una conexión con un servidor. Si tienes tres servidores configurados, el host levanta tres clientes.
• Servidor: el servicio que ofrece contexto y capacidades. Puede correr en tu máquina como un proceso local o vivir detrás de una URL.

La distinción importa por una razón práctica: la seguridad y el consentimiento son responsabilidad del host, no del servidor. Un servidor MCP no valida si tú querías que se leyera ese archivo; declara lo que sabe hacer y espera. El que pregunta "¿autorizas esta herramienta?" es el host. Cualquier explicación que ponga la seguridad del lado del servidor te está contando el modelo al revés, y es la confusión que hace que un servidor malicioso funcione.

Todos los mensajes viajan como JSON-RPC 2.0. Si quieres ver el detalle de lo que pasa por el cable, la negociación y los tipos de mensaje, eso lo desmenuzo en MCP por dentro.

Qué expone un servidor: tools, resources y prompts

Un servidor no ofrece una sola cosa. Declara sus capacidades en tres categorías y el cliente las descubre a través del protocolo:

• Tools: funciones que el modelo puede invocar con argumentos (consultar una API, escribir un archivo, correr una query). Es el 90% de lo que verás en la práctica.
• Resources: contexto y datos que el servidor pone a disposición, para el usuario o para el modelo (documentos, registros, esquemas).
• Prompts: plantillas de mensajes y flujos de trabajo, pensadas para que el usuario las invoque.

La dirección también funciona al revés, aunque menos gente lo sabe: el cliente puede ofrecer capacidades al servidor. Hoy la principal es elicitation, que permite a un servidor pedir información adicional al usuario a mitad de una operación en vez de fallar por falta de datos.

La revisión vigente es stateless, y eso cambia cosas

Este es el punto donde la mayoría de los artículos sobre MCP que encontrarás están desactualizados, incluido este hasta hace poco.

La revisión vigente de la especificación es 2026-07-28, y su protocolo base se define con dos frases que conviene leer despacio: peticiones stateless y autocontenidas, y negociación de capacidades por petición. Es decir, ya no hay un handshake inicial que abre una sesión con estado que ambas partes arrastran. Cada petición lleva lo que necesita.

Para quien implementa, las consecuencias son grandes: desaparecen las sesiones y la resumabilidad, y un servidor deja de tener que recordar quién eres entre llamadas. Para quien despliega, es la diferencia entre necesitar un proceso con estado y poder poner un servidor MCP detrás de una función serverless sin trucos. Lo que se fue, lo que queda y lo que está en camino de salida lo detallo en MCP se vuelve stateless.

Sobre el núcleo, la especificación define además extensiones opcionales que ambas partes tienen que soportar explícitamente. Las tres que vale la pena conocer: Tasks para operaciones largas y asíncronas con handles duraderos, Skills over MCP para servir instrucciones estructuradas de flujos de trabajo, y MCP Apps para devolver interfaz (gráficas, formularios) dentro de la conversación en vez de solo texto.

Cuándo usar MCP y cuándo no

Tiene sentido si tu aplicación necesita hablar con varias herramientas externas, si quieres que esas herramientas sean intercambiables sin reescribir la aplicación, o si necesitas un punto claro donde pedir consentimiento y registrar qué se ejecutó.

No hace falta si tu agente hace una sola cosa contra una sola API. Un servidor MCP para envolver una única llamada HTTP es infraestructura que no te devuelve nada. Llama a la API.

Y hay un tercer caso que conviene tener presente: para darle a un agente instrucciones sobre cómo trabajar, MCP no siempre es la herramienta. Ese debate, con la llegada de las skills, lo trato en ¿han muerto los MCP por culpa de Skills?.

Por dónde seguir

Este artículo es la entrada del tema, y la guía de MCP tiene el recorrido completo agrupado por para qué lo necesitas. Si prefieres ir directo:

• Ver el protocolo por dentro: MCP por dentro, el modelo host-cliente-servidor y JSON-RPC en detalle.
• Escribir tu primer servidor: cómo crear un servidor MCP en TypeScript, con el SDK oficial y MCP Inspector.
• Usar servidores que ya existen: mejores servidores MCP para desarrolladores.
• Conectarlos a tu editor: conectar un servidor MCP a Cursor y Claude Code.
• Exponer una app Laravel: MCP para Laravel.
• Entender los riesgos: servidores MCP maliciosos, porque un servidor es código ejecutándose con tus permisos.

Un ejemplo real que uso a diario es Context7, un servidor MCP que le da a Claude y Cursor documentación siempre actualizada en vez de la que recuerdan del entrenamiento.

Preguntas frecuentes

¿Qué significa MCP en inteligencia artificial?

Model Context Protocol: un estándar abierto que define cómo una aplicación de IA descubre e invoca herramientas y datos externos, usando mensajes JSON-RPC 2.0. Ojo con las siglas, porque MCP también significa otras cosas fuera de este contexto.

¿MCP funciona con cualquier modelo?

El protocolo es agnóstico del modelo, pero la compatibilidad no es del modelo: es de la aplicación. Un modelo no "soporta MCP"; lo soporta el host que lo envuelve. Claude, ChatGPT, Cursor y VS Code lo implementan, y dentro de ellos puedes usar el modelo que ofrezcan.

¿Tengo que implementar un servidor MCP?

No. Esa es la confusión más común. Para usar MCP solo necesitas una aplicación que lo soporte y configurar un servidor que ya exista. Escribir un servidor propio solo hace falta cuando quieres exponer una herramienta o unos datos que nadie ha expuesto todavía.

¿Qué expone un servidor MCP?

Tres tipos de capacidades: tools (funciones que el modelo invoca), resources (contexto y datos) y prompts (plantillas de mensajes y flujos). El cliente las descubre por el protocolo, sin configuración manual.

¿Cuál es la versión actual de MCP?

La revisión vigente de la especificación es 2026-07-28. Su cambio de fondo respecto a las anteriores es que el protocolo base pasó a ser stateless: peticiones autocontenidas y negociación de capacidades por petición, sin sesión con estado.

¿MCP es seguro?

El protocolo define principios de consentimiento, privacidad y seguridad de herramientas, pero no puede imponerlos: la especificación dice explícitamente que la responsabilidad recae en quien implementa. Un servidor MCP es código ejecutándose con tus permisos, y las descripciones de sus herramientas deben tratarse como no confiables si el servidor no lo es. Cómo se explota eso en la práctica está en servidores MCP maliciosos.

¿Dónde está la especificación oficial?

En modelcontextprotocol.io, con el esquema TypeScript de cada revisión publicado en el repositorio de la especificación. Es la fuente que manda: cualquier artículo, incluido este, va por detrás de ella.