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

Todo asistente de IA se topa con el mismo límite: sabe mucho sobre el mundo hasta la fecha de corte de su entrenamiento, pero no sabe nada sobre tus archivos, tu base de datos o la API interna de tu empresa. El Model Context Protocol (MCP) nació para cerrar exactamente esa brecha. Desde que Anthropic lo lanzó como estándar abierto a finales de 2024, se ha convertido, en la práctica, en una especie de USB-C para conectar modelos de lenguaje a herramientas y datos externos.

Qué es el MCP

El Model Context Protocol es un protocolo abierto, basado en JSON-RPC 2.0, que define una forma estandarizada para que un modelo de lenguaje (o la aplicación que lo aloja) se conecte a fuentes de datos y herramientas externas. En lugar de que cada asistente de IA reinvente su propia forma de leer un archivo, consultar una base de datos o ejecutar una automatización, el MCP ofrece una interfaz común que cualquier servidor puede implementar y cualquier cliente puede consumir.

En la práctica, esto significa que quien construye una integración, por ejemplo un conector para GitHub o para Google Drive, hace ese trabajo una sola vez, en forma de un servidor MCP. Cualquier aplicación compatible, como Claude Desktop, Claude Code, un IDE o un agente personalizado, puede usar esa integración sin escribir ningún código específico para ella. El protocolo organiza la comunicación en tres bloques: tools (acciones que el modelo puede ejecutar), resources (datos que el modelo puede leer) y prompts (plantillas de instrucción reutilizables), todos descritos en un formato que el propio modelo interpreta en tiempo de ejecución.

El problema que resuelve el MCP

Antes del MCP, conectar un LLM a un sistema externo generalmente significaba escribir una integración a medida: un plugin aquí, una function calling personalizada allá, un agente rodeado de wrappers de API específicos. Cada aplicación de IA tenía su propia forma de exponer herramientas, y cada herramienta necesitaba ser adaptada para cada aplicación. Si una empresa mantenía 5 herramientas internas y quería que funcionaran en 3 asistentes diferentes, el resultado eran 15 integraciones separadas que mantener, cada una con su propio esquema de autenticación y formato de solicitud.

Este es el clásico problema de "M por N": M herramientas multiplicadas por N aplicaciones generan M×N puentes de integración. El MCP aplana esa ecuación a M+N. Cada herramienta se convierte en un servidor MCP, construido una sola vez; cada aplicación se convierte en un cliente MCP compatible, también construido una sola vez; y cualquier combinación entre ambos lados funciona sin trabajo extra. Es básicamente el mismo razonamiento detrás del Language Server Protocol, creado años antes para que los editores de código dejaran de necesitar implementar soporte nativo para cada lenguaje de programación por separado.

Arquitectura del protocolo

El MCP sigue una arquitectura cliente-servidor con tres roles bien definidos:

• Host: la aplicación que el usuario final usa directamente, como Claude Desktop, un IDE con IA integrada o un agente propio.
• Cliente MCP: un componente dentro del host que mantiene una conexión individual y aislada con un servidor MCP específico.
• Servidor MCP: un proceso separado, local o remoto, que expone tools, resources y prompts sobre un sistema externo.

Un mismo host puede mantener varios clientes MCP al mismo tiempo, cada uno conectado a un servidor diferente: uno para el sistema de archivos, otro para Slack, otro para una base de datos Postgres. Esta regla de un cliente por servidor es intencional, porque garantiza aislamiento. Una falla o bloqueo en un servidor no derriba la conexión con los demás.

El diagrama a continuación resume este diseño:

La comunicación entre cliente y servidor se realiza mediante dos transportes principales. Para servidores locales, el estándar es stdio, la entrada y salida estándar del proceso, simple y rápido porque no requiere red. Para servidores remotos, el transporte es HTTP con Streamable HTTP, la evolución del antiguo transporte basado en Server-Sent Events, lo que permite alojar un servidor MCP en la nube y atender a varios clientes al mismo tiempo.

El cliente MCP

El cliente vive dentro del host y se encarga de tres cosas: abrir y mantener la conexión con un servidor, traducir las decisiones del modelo en mensajes JSON-RPC, y devolver las respuestas del servidor al contexto de la conversación. En la práctica, el cliente también realiza el handshake inicial, la etapa de initialize en la que cliente y servidor intercambian información de versión del protocolo y capacidades soportadas, además del proceso de descubrimiento, en el que pregunta al servidor qué tools, resources y prompts ofrece.

Un detalle poco obvio es que el cliente no decide por sí solo cuándo usar una herramienta. Esa decisión es del modelo: el cliente entrega al LLM la lista de tools disponibles, formateada como parte del contexto de la conversación, y es el propio modelo el que elige, según lo que el usuario pidió, si llamar a una herramienta y a cuál. El cliente solo ejecuta la llamada técnica después de que el modelo ya ha decidido.

El servidor MCP

Del otro lado, el servidor es quien realmente sabe interactuar con el sistema externo, ya sea una base de datos, una API de terceros o el sistema de archivos local. Un servidor MCP bien construido expone sus capacidades de forma autodescriptiva: cada tool viene con un nombre, una descripción en lenguaje natural y un schema, generalmente JSON Schema, que define qué parámetros acepta.

Esta autodescripción es lo que hace que el MCP sea conectable. El servidor no necesita saber qué modelo lo va a consumir, y el cliente no necesita ningún código específico para ese servidor más allá de hablar el protocolo. Hoy ya existen cientos de servidores MCP publicados por empresas como GitHub, Stripe, Cloudflare y Sentry, además de un gran ecosistema de servidores comunitarios para bases de datos, herramientas de productividad y servicios internos.

Las herramientas (tools) del MCP

Las tools son el tipo de capacidad más usado en el MCP: acciones que el modelo puede ejecutar y que normalmente tienen efecto secundario o devuelven un resultado computado, como consultar el pronóstico del tiempo, crear una tarjeta en Trello o ejecutar una consulta SQL. El protocolo define dos tipos de capacidad más que vale la pena conocer:

• Resources: datos que el servidor expone para lectura, como el contenido de un archivo, una fila de base de datos o el resultado de una consulta. A diferencia de las tools, los resources normalmente no tienen efecto secundario, son solo contexto que el host puede adjuntar a la conversación.
• Prompts: plantillas de instrucción reutilizables que el servidor pone a disposición, como un guion listo para revisar un pull request o resumir un ticket de soporte, que el usuario puede invocar directamente.

Cada tool se describe con un objeto que contiene name, description e inputSchema. Es esta descripción, escrita en lenguaje natural pero estructurada, la que permite al modelo entender qué hace la herramienta sin que nadie tenga que programar reglas explícitas sobre cuándo usarla.

Flujo completo de una llamada MCP

Para entender cómo todo esto se conecta en la práctica, vale la pena seguir el ciclo de vida de una llamada real, tal como viaja entre cliente y servidor a través de JSON-RPC 2.0.

Primero, en la conexión, el cliente pregunta qué herramientas ofrece el servidor:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

El servidor responde con la lista completa, incluyendo ya el schema de cada herramienta:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Devuelve el pronóstico del tiempo actual de una ciudad",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

Este catálogo se entrega al modelo como parte del contexto disponible. Cuando el usuario hace una solicitud que el modelo interpreta como algo que requiere la herramienta get_weather, el cliente arma y envía una llamada tools/call:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "city": "São Paulo" }
  }
}

El servidor ejecuta la lógica real detrás de la herramienta, en este caso probablemente una llamada a una API de clima real, y devuelve el resultado en el mismo formato JSON-RPC:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      { "type": "text", "text": "23°C, cielo despejado en São Paulo" }
    ]
  }
}

El cliente inyecta este resultado de vuelta en la conversación, y el modelo usa la información para formular la respuesta final al usuario. Desde el punto de vista de quien conversa con el asistente, todo esto ocurre de forma transparente: solo se ve la pregunta y la respuesta, sin saber que, en segundo plano, hubo una negociación completa del protocolo.

MCP vs API tradicional

Es común que surja la duda: si toda herramienta externa ya tiene una API REST, ¿por qué no usar esa API directamente? La respuesta está en la diferencia entre integrar un sistema para que un desarrollador humano lea la documentación e integrar un sistema para que un modelo lo descubra y lo use por sí mismo, en tiempo real.

Aspecto	API REST tradicional	MCP
Descubrimiento de capacidades	Documentación externa (Swagger/OpenAPI), leída por un humano	El cliente pregunta al servidor en tiempo real qué tools existen (tools/list)
Integración por sistema	Un conector dedicado para cada API	Un único protocolo estándar para cualquier servidor MCP
Formato de comunicación	HTTP + JSON, esquema varía por proveedor	JSON-RPC 2.0 estandarizado
Contexto para el modelo	El desarrollador decide manualmente qué exponer al LLM	El servidor describe tools de forma que el propio modelo decide qué usar
Transporte	Casi siempre HTTP	stdio (local) o HTTP con Streamable HTTP (remoto)
Reutilización entre apps de IA	Baja, cada app reimplementa la integración	Alta, cualquier host compatible usa el mismo servidor

En la práctica, el MCP no reemplaza la API REST detrás del servidor, es una capa de estandarización sobre ella. Un servidor MCP para GitHub, por ejemplo, probablemente llama a la API REST de GitHub internamente. La diferencia es que el modelo nunca necesita saberlo: solo ve tools con nombres y schemas consistentes, sin importar qué API está detrás.

Ejemplo práctico: un servidor MCP simple

Para sacar el protocolo del papel, un servidor MCP mínimo en Python, usando el SDK oficial con la clase FastMCP, cabe en pocas líneas:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("clima-server")
@mcp.tool()
def get_weather(city: str) -> str:
    """Devuelve el pronóstico del tiempo actual de una ciudad."""
    # la llamada real a una API de clima iría aquí
    return f"23°C, cielo despejado en {city}"
if name == "main":
    mcp.run(transport="stdio")

Este servidor expone una única tool llamada get_weather. El decorador @mcp.tool() ya se encarga de generar el schema JSON a partir de la firma de la función y el docstring, por lo que no es necesario escribir el JSON Schema a mano. Al ejecutar este script, queda escuchando a través de stdio, listo para que cualquier cliente MCP, como Claude Desktop configurado localmente, se conecte y descubra la herramienta automáticamente.

Este ejemplo es intencionalmente simple, pero el mismo patrón aplica para servidores más complejos: la lógica de negocio (consultar una base de datos, llamar a una API de pago, ejecutar una automatización) va en el cuerpo de la función, y el SDK se encarga de toda la parte del protocolo, handshake y serialización.

Seguridad en el MCP

Darle a un modelo de lenguaje acceso directo a herramientas que leen archivos, escriben en bases de datos o llaman a APIs de terceros plantea una pregunta obvia: ¿quién garantiza que esto no se salga de control? El protocolo define algunas salvaguardas, pero la responsabilidad final se divide entre el servidor, el cliente y quien configura el sistema.

A nivel del servidor, la buena práctica es aplicar el principio del menor privilegio: un servidor MCP para el sistema de archivos, por ejemplo, debe restringir el acceso a directorios específicos, nunca al disco completo. Los servidores remotos que usan transporte HTTP normalmente exigen autenticación mediante OAuth 2.1, y la especificación del protocolo trata esto con bastante detalle, precisamente porque los servidores mal configurados son el vector de ataque más obvio.

A nivel del cliente y del host, la capa de seguridad más visible para el usuario final es el consentimiento humano: hosts como Claude Desktop piden confirmación antes de ejecutar tools sensibles, como escribir un archivo o enviar un mensaje, especialmente la primera vez que se usa una herramienta. También existe el riesgo de prompt injection a través de resources, cuando un contenido malicioso incrustado en un documento que el modelo lee intenta manipular al modelo para que ejecute una acción indebida. Los servidores que exponen contenido de fuentes no confiables, como páginas web o correos electrónicos recibidos, merecen atención redoblada tanto de quien construye el servidor como de quien decide conectarlo a un agente con permisos amplios.

Limitaciones del MCP

El MCP resuelve el problema de estandarización, pero no es una solución mágica para todo. Vale la pena conocer los límites reales antes de decidir construir sobre él.

Primero, el protocolo aún es relativamente nuevo, lanzado a finales de 2024, y el ecosistema, aunque crece rápido, todavía tiene lagunas: no todas las herramientas populares tienen ya un servidor MCP maduro y mantenido oficialmente. Segundo, más tools disponibles al mismo tiempo significan más tokens gastados describiendo esas tools en el contexto de la conversación, lo que puede encarecer las llamadas y, en casos extremos, competir por espacio de contexto con el resto de la conversación. Tercero, el protocolo no resuelve por sí solo el problema de confiabilidad del modelo: este aún puede elegir la tool incorrecta, armar argumentos incorrectos o interpretar mal un resultado devuelto por el servidor, por lo que la orquestación cuidadosa sigue siendo trabajo de quien construye el agente.

Por último, la autenticación y la gobernanza de acceso en entornos corporativos, es decir, quién puede conectar qué servidor, con qué permisos, auditado de qué forma, sigue siendo un área en maduración, con bastante trabajo en la comunidad y en las empresas que adoptan el protocolo en producción.

FAQ

¿El MCP es exclusivo de Anthropic y Claude?

No. El MCP es un protocolo abierto, con especificación pública, y otras empresas de IA y frameworks de agentes ya han anunciado soporte para él, aunque nació dentro de Anthropic.

¿Necesito saber programar para usar un servidor MCP?

Para usar un servidor ya listo, como el de acceso a archivos o a Google Drive, dentro de una app como Claude Desktop, no. Programar es necesario solo para quien quiere construir un servidor nuevo desde cero.

¿MCP reemplaza a function calling?

No exactamente. Function calling es la capacidad del modelo de elegir y formatear una llamada de herramienta. El MCP usa esa capacidad internamente, pero añade la capa de descubrimiento, estandarización y transporte entre cliente y servidor que el function calling por sí solo no define.

¿Un servidor MCP puede ejecutarse en la nube?

Sí. Los servidores remotos usan transporte HTTP y pueden alojarse normalmente, atendiendo a varios clientes al mismo tiempo, con autenticación mediante OAuth.

La ganancia real del MCP no es técnica en el sentido de "una API más", es organizacional: transforma un problema que crecía de forma multiplicativa, cada herramienta para cada aplicación, en un problema que crece de forma aditiva. Para quienes construyen agentes de IA hoy, entender este protocolo ha dejado de ser opcional. Ya es la pieza de infraestructura más cercana a un estándar de facto para conectar modelos a todo lo que existe fuera del propio modelo.