- MCP es un protocolo abierto basado en JSON-RPC 2.0 publicado por Anthropic en noviembre de 2024.
- Define tres primitivas: Tools (funciones invocables), Resources (fuentes de datos) y Prompts (plantillas de instrucciones).
- Soporta dos transportes: stdio para procesos locales y HTTP con SSE para servidores remotos.
- A mayo de 2026 existían más de 5.800 servidores MCP públicos en el ecosistema comunitario.
- Clientes principales: Claude Code, Claude Desktop, Cursor, VS Code, Zed y Continue.dev.
Qué es MCP y por qué resuelve un problema real en los agentes IA
Antes de MCP, cada agente de IA que quería conectarse a una herramienta — una base de datos, un servicio REST, el sistema de archivos del sistema operativo — necesitaba su propia integración a medida. Si tenías diez herramientas y cinco modelos distintos, terminabas manteniendo cincuenta integraciones diferentes con sus propios formatos, autenticaciones y esquemas de datos. La explosión del ecosistema de agentes en 2024-2025 hizo que este problema fuera insostenible.
Anthropic publicó el Model Context Protocol en noviembre de 2024 para resolver exactamente ese problema. MCP define un protocolo estandarizado de comunicación entre tres actores: el host (la aplicación que aloja el modelo, como Claude Code o Cursor), el cliente MCP (integrado en el host, gestiona la conexión al protocolo) y el servidor MCP (el proceso externo que expone las herramientas y los datos).
El resultado es una matriz N×M donde N herramientas se conectan a M modelos con cero código de integración específico: cualquier servidor MCP funciona con cualquier cliente MCP. La especificación completa está disponible en spec.modelcontextprotocol.io .
Por qué MCP importa para el futuro de los agentes
La adopción de MCP ha superado las expectativas iniciales. A mayo de 2026, no solo los clientes de Anthropic lo soportan: Cursor, VS Code, Zed, Continue.dev y docenas de plataformas más lo han integrado como mecanismo de extensión principal. El repositorio oficial de servidores MCP en GitHub mantiene una lista curada de servidores de referencia, mientras que la comunidad ha publicado miles de implementaciones propias.
Para los desarrolladores, esto significa que construir un servidor MCP que exponga una API interna o una base de datos propietaria equivale a hacer esa herramienta accesible para todos los agentes que el equipo use, hoy y en el futuro, sin depender del modelo específico ni del cliente concreto que se adopte. Es una inversión con un multiplicador muy alto.
Cómo funciona la arquitectura cliente-servidor de MCP
MCP sigue una arquitectura en tres capas bien diferenciadas. Entender cada capa es fundamental para implementar o depurar cualquier integración MCP.
Las tres capas del protocolo
Host
La aplicación que contiene el modelo de lenguaje y orquesta toda la interacción. Claude Code, Claude Desktop y Cursor son ejemplos de hosts. El host crea instancias del cliente MCP, gestiona las conexiones a los servidores y es responsable de decidir qué herramientas expone al modelo en cada contexto.
Cliente MCP
Módulo interno del host que implementa el protocolo MCP en el lado del consumidor. Mantiene una conexión 1:1 con un servidor MCP, envía peticiones en formato JSON-RPC 2.0 y recibe las respuestas. Un host puede mantener múltiples clientes conectados simultáneamente a distintos servidores.
Servidor MCP
Proceso externo (local o remoto) que expone capacidades al modelo: herramientas para ejecutar acciones, recursos para consultar datos y plantillas de prompts. El servidor no sabe nada del modelo ni del host: solo sabe que alguien le envía peticiones JSON-RPC y él debe responder según el contrato del protocolo.
JSON-RPC 2.0 como formato de mensajes
Toda la comunicación entre cliente y servidor usa JSON-RPC 2.0 , un protocolo ligero y bien establecido que define el formato de peticiones, respuestas y notificaciones. Un mensaje de petición tiene esta forma:
| Campo | Tipo | Descripción |
|---|---|---|
jsonrpc |
string | Siempre "2.0" |
method |
string | Nombre del método: tools/call, resources/read, etc. |
params |
object | Parámetros específicos del método |
id |
string | number | Identificador de la petición para correlacionar con la respuesta |
Los dos transportes: stdio y SSE/HTTP
MCP define dos mecanismos de transporte para enviar los mensajes JSON-RPC:
Primitivas de MCP: Tools, Resources y Prompts
Un servidor MCP puede exponer tres tipos de capacidades, llamadas "primitivas" en la especificación. Cada una tiene un propósito diferente y un mecanismo de interacción distinto con el modelo.
Tools — herramientas ejecutables
Las Tools son funciones que el modelo puede invocar activamente para ejecutar acciones con efectos en el mundo real. Ejemplos: llamar a una API REST, ejecutar una consulta SQL, crear un archivo, enviar un email. El servidor declara el nombre de la tool, su descripción y el esquema JSON de sus parámetros de entrada. El modelo decide cuándo invocar cada tool en función de la tarea que está resolviendo. Son la primitiva más utilizada y el equivalente al "function calling" de otros sistemas.
Resources — fuentes de datos
Los Resources son contenidos que el servidor expone para que el host los incluya en el contexto del modelo. A diferencia de las Tools, los Resources no ejecutan acciones: son datos — el contenido de un archivo, el resultado de una consulta, la respuesta de una API de solo lectura. El host puede suscribirse a actualizaciones de un Resource para que el modelo siempre tenga la versión más reciente. Son especialmente útiles para datos que cambian con frecuencia y que el modelo necesita consultar de forma repetida.
Prompts — plantillas de instrucciones
Los Prompts son plantillas de instrucciones predefinidas que el servidor puede sugerir al usuario o al host para guiar el comportamiento del modelo. Por ejemplo, un servidor MCP de base de datos podría ofrecer un Prompt "analiza el rendimiento de la consulta X" que ya incluye todo el contexto necesario. Los Prompts pueden ser estáticos o parametrizados, y permiten encapsular "recetas" de uso comunes que de otro modo el usuario tendría que escribir manualmente.
| Primitiva | Propósito | Quién la inicia | Efectos | Ejemplo típico |
|---|---|---|---|---|
| Tools | Ejecutar acciones | El modelo | Puede modificar estado externo | Crear fichero, llamar API, ejecutar SQL |
| Resources | Consultar datos | El host | Solo lectura | Leer archivo, obtener respuesta de API |
| Prompts | Guiar comportamiento | El usuario o el host | Ninguno | Plantilla de análisis, wizard de configuración |
Servidores MCP: ecosistema y cómo construir el tuyo
El catálogo de servidores MCP ha crecido de cero a más de 5.800 en menos de dos años. Aquí tienes los más relevantes y los pasos para crear uno propio.
Servidores MCP más utilizados a mayo de 2026
| Servidor | Función | Primitivas | Transporte |
|---|---|---|---|
| Filesystem | Acceso al sistema de archivos local con permisos configurables | Tools, Resources | stdio |
| GitHub | Repositorios, issues, pull requests y releases via API de GitHub | Tools, Resources | stdio / SSE |
| PostgreSQL | Consultas SQL e inspección del schema de la base de datos | Tools, Resources | stdio |
| Brave Search | Búsqueda web y local vía la API de Brave | Tools | stdio |
| Slack | Lectura de canales, envio de mensajes y gestión de espacios de trabajo | Tools, Resources | stdio |
| Google Maps | Geocodificación, direcciones y busqueda de lugares | Tools | stdio |
| Fetch | Descarga de páginas web y conversión a formato Markdown | Tools | stdio |
| Memory | Grafo de conocimiento persistente para el modelo | Tools, Resources | stdio |
Cómo construir tu propio servidor MCP
Anthropic publica SDKs oficiales en TypeScript y Python que abstraen toda la implementación del protocolo. El proceso para crear un servidor MCP propio tiene cuatro pasos:
1. Instalar el SDK
Para TypeScript: npm install @modelcontextprotocol/sdk.
Para Python: pip install mcp. Los SDKs se encargan de toda
la comunicación JSON-RPC, la gestión de conexiones y la serialización de mensajes.
La especificación de referencia del SDK está en
github.com/modelcontextprotocol .
2. Definir las Tools o Resources que quieres exponer
Cada Tool necesita un nombre único, una descripción en lenguaje natural que el modelo usará para decidir cuándo invocarla, y un esquema JSON de los parámetros de entrada. La descripción es crítica: un modelo bien informado seleccionará la tool correcta en el momento correcto.
3. Implementar el handler de cada primitiva
La función que se ejecuta cuando el modelo invoca la Tool. Aquí va la lógica real: llamar a la base de datos, invocar la API externa, leer el archivo. El SDK se encarga de deserializar los parámetros de entrada y serializar la respuesta de vuelta al cliente.
4. Lanzar el servidor con el transporte elegido
Para uso local: server.connect(new StdioServerTransport()).
Para uso remoto: configurar el servidor HTTP con SSE. Con stdio, el servidor
está listo para que el host lo lance como subproceso. Con SSE, solo necesitas
desplegarlo en cualquier servidor web accesible.
Qué clientes son compatibles con MCP a 2026
La lista de clientes MCP crece cada mes. Estos son los más relevantes a mayo de 2026 y su nivel de soporte del protocolo.
.claude/settings.json. Soporta tanto stdio como SSE. Es el cliente de referencia
para las implementaciones de nuevos servidores. Para profundizar, la guía de
Claude Code detalla la configuración completa.
.vscode/mcp.json y son accesibles
desde el panel de chat de la extensión sin configuración adicional.
Ejemplo práctico: conectar un servidor MCP a Claude Code
Veamos cómo funciona una sesión MCP real, paso a paso, usando el servidor de sistema de archivos como ejemplo. Este servidor permite que Claude Code lea y escriba archivos fuera del directorio de trabajo actual, con permisos configurables.
Paso 1: instalar el servidor MCP de sistema de archivos
El servidor oficial de filesystem está publicado en npm. Con un solo comando
queda disponible: npm install -g @modelcontextprotocol/server-filesystem.
No requiere configuración de infraestructura ni puertos abiertos porque usa el
transporte stdio.
Paso 2: declarar el servidor en la configuración de Claude Code
En el archivo .claude/settings.json del proyecto (o en el settings.json
global del usuario), se declara el servidor MCP con el comando que lo lanza y
los directorios a los que puede acceder. Claude Code lanzará ese proceso
automáticamente al iniciar una sesión.
Paso 3: el host establece la conexión
Al arrancar, Claude Code lanza el servidor como subproceso y envía un mensaje
initialize para negociar las capacidades. El servidor responde con
la lista de Tools y Resources que expone. A partir de ese momento, Claude Code
sabe qué herramientas tiene disponibles para esta sesión.
Paso 4: el modelo invoca las Tools cuando las necesita
Cuando el usuario pide al agente que analice documentación en una carpeta fuera
del proyecto, Claude identifica la Tool read_file del servidor de
filesystem como la forma de obtener ese contenido, la invoca con el parámetro
de ruta, y el servidor devuelve el contenido del archivo. El modelo procesa la
respuesta como si fuera contexto adicional del prompt.
Paso 5: el resultado vuelve al usuario
El modelo integra la información obtenida del servidor MCP en su respuesta final al usuario. Desde la perspectiva del usuario, el agente simplemente "sabe" lo que hay en esa carpeta. Desde la perspectiva técnica, se ha producido un ciclo completo de host → cliente → servidor → cliente → host completamente transparente.
MCP frente a otras aproximaciones para conectar herramientas
Function calling de OpenAI, las herramientas nativas de LangChain y MCP resuelven problemas similares con filosofías distintas. Esta tabla recoge las diferencias clave.
| Dimensión | MCP | OpenAI Function Calling | LangChain Tools |
|---|---|---|---|
| Tipo | Protocolo abierto e independiente del modelo | Mecanismo propietario de la API de OpenAI | Abstracción Python de framework |
| Independencia del modelo | Total — cualquier modelo compatible | Solo modelos de OpenAI | Multi-modelo vía adaptadores |
| Independencia del cliente | Total — cualquier cliente MCP | Atado al ecosistema OpenAI | Solo aplicaciones Python con LangChain |
| Servidores reutilizables | Sí — un servidor vale para todos los clientes | No — cada integración es específica | Parcialmente — requiere Python |
| Resources (datos de contexto) | Sí — primitiva nativa | No — solo function calling | Via Document Loaders y Retrievers |
| Transporte estandarizado | stdio + SSE | HTTPS (propietario) | Llamada de función Python |
| Ecosistema de servidores | +5.800 públicos a mayo 2026 | GPTs y plugins (restringido) | +600 integraciones Python |
| Mejor para | Interoperabilidad entre herramientas y modelos | Proyectos cerrados en el ecosistema OpenAI | Pipelines complejos en Python |
La ventaja estructural de MCP sobre el function calling de OpenAI es la separación entre el proveedor del modelo y el proveedor de la herramienta. Con function calling, si cambias de GPT-5 a Claude o a un modelo open source, tienes que reescribir o adaptar todas tus integraciones de herramientas. Con MCP, el servidor MCP no cambia: solo necesitas que el nuevo cliente sea compatible con el protocolo.
Respecto a LangChain Tools, la diferencia principal es que las herramientas de LangChain son código Python que se ejecuta en el mismo proceso que el agente. Los servidores MCP son procesos independientes que pueden estar escritos en cualquier lenguaje, que pueden desplegarse de forma independiente y que pueden ser consumidos por clientes en cualquier lenguaje. Para integraciones complejas y a largo plazo, MCP tiene una mejor separación de responsabilidades.
Profundiza en MCP
Guías detalladas para cada aspecto del protocolo: desde la teoría hasta la implementación práctica.
Preguntas frecuentes sobre MCP
¿Qué es MCP o Model Context Protocol?
MCP (Model Context Protocol) es un protocolo abierto publicado por Anthropic que define un estándar de comunicación entre modelos de lenguaje y herramientas externas. Funciona como el "USB-C de la IA": cualquier cliente compatible (Claude Code, Cursor, VS Code) puede conectarse a cualquier servidor MCP sin código de integración específico para cada par herramienta-modelo. La especificación completa está disponible en spec.modelcontextprotocol.io .
¿Cómo funciona MCP internamente?
MCP usa JSON-RPC 2.0 como formato de mensajes. El transporte puede ser stdio (proceso local) o HTTP con Server-Sent Events (SSE) para servidores remotos. La comunicación siempre fluye del host al cliente y del cliente al servidor: el host (por ejemplo Claude Code) invoca al cliente, que traduce las peticiones al protocolo MCP y se las envía al servidor MCP que expone las herramientas. El modelo nunca interactúa directamente con el servidor: siempre pasa por el host y el cliente.
¿Cuáles son las primitivas de MCP?
MCP define tres primitivas principales. Tools son funciones que el modelo puede invocar para ejecutar acciones: llamar a APIs, leer archivos, ejecutar comandos. Resources son fuentes de datos que el servidor expone para que el modelo las consulte: contenido de archivos, resultados de base de datos, respuestas de APIs. Prompts son plantillas de instrucciones reutilizables que el servidor puede sugerir al modelo para guiar su comportamiento.
¿Qué clientes son compatibles con MCP?
A mayo de 2026 los principales clientes MCP son Claude Code (CLI de Anthropic), Claude Desktop (aplicación de escritorio), Cursor (IDE), VS Code con la extensión oficial de Anthropic, Zed y Continue.dev. La lista crece con rapidez a medida que los IDEs y plataformas de agentes adoptan el protocolo. La página oficial mantiene una lista actualizada en modelcontextprotocol.io .
¿Puedo crear mi propio servidor MCP?
Sí. Anthropic publica SDKs oficiales en TypeScript/JavaScript y Python que abstraen toda la implementación del protocolo. Basta con definir las Tools, Resources o Prompts que quieres exponer, registrarlas con el SDK y lanzar el servidor. En menos de 50 líneas de código puedes tener un servidor MCP funcional que expone una API REST o un sistema de archivos a cualquier cliente compatible. El repositorio de referencia está en github.com/modelcontextprotocol/servers .