MCP: qué es y cómo funciona el protocolo de Anthropic

⏱️ Lectura: 16 min

Earendil, la empresa que desarrolla el asistente de código Pi, escribió durante meses en su blog y repitió en podcasts que Pi no soportaría MCP. En la versión más reciente del producto, MCP pasó a formar parte del núcleo.

📑 En este artículo

1. TL;DR
2. ¿Qué es Model Context Protocol?
3. Por qué importa el giro de Pi
4. Cómo funciona MCP por dentro
5. Ejemplos prácticos
6. Cómo empezar
7. Casos de uso reales
   1. Tabla comparativa: MCP frente a otras formas de conectar herramientas
8. Errores comunes y buenas prácticas
9. Profundizando: cómo escala MCP con Codemode
10. Preguntas frecuentes
    1. ¿Qué diferencia a MCP de una API REST tradicional?
    2. ¿Necesito saber JavaScript para usar Codemode con MCP?
    3. ¿MCP es exclusivo de Claude?
    4. ¿Un servidor MCP puede acceder a mi sistema de archivos sin permiso?
    5. ¿Por qué Pi rechazó MCP al principio y qué le hizo cambiar de opinión?
    6. ¿Qué es Codemode y en qué se diferencia de un servidor MCP común?
11. Referencias
    1. 📚 Artículos relacionados

El giro no es cosmético: expone qué es realmente el protocolo, cómo cambió en el último año y por qué hasta sus críticos más ruidosos terminan integrándolo.

TL;DR

• MCP es el protocolo abierto de Anthropic que estandariza cómo un modelo conecta con herramientas y datos externos.
• Un servidor MCP expone herramientas mediante JSON-RPC; cualquier cliente compatible las descubre sin código a medida.
• Codemode añade un sandbox de JavaScript para combinar varias llamadas MCP sin gastar contexto en cada paso.
• Pi, el asistente de Earendil, pasó de rechazar MCP en su blog a integrarlo en el núcleo del producto.
• Configurar un servidor MCP propio toma un archivo JSON y un comando npx, sin infraestructura adicional.

¿Qué es Model Context Protocol?

MCP (Model Context Protocol) es un protocolo abierto publicado por Anthropic que estandariza cómo un modelo de lenguaje se conecta con herramientas, archivos y servicios externos. En vez de programar una integración distinta por cada fuente de datos, un cliente y un servidor MCP comparten el mismo lenguaje: JSON-RPC sobre un transporte común.

Antes de MCP, cada asistente de IA (un editor, un CLI, un chatbot) necesitaba su propio conector para cada servicio: uno para Slack, otro para una base de datos, otro para el sistema de archivos. MCP separa esos dos roles. Un servidor MCP expone un conjunto de capacidades (herramientas para ejecutar acciones, recursos para leer datos, prompts reutilizables). Un cliente MCP, que vive dentro del asistente, descubre esas capacidades al conectarse y decide cuáles mostrarle al modelo en cada turno.

Por dentro, una llamada a una tool de MCP no es muy distinta del function calling que ya soportan las APIs de los modelos: el servidor anuncia el nombre de la función, su descripción y su esquema de parámetros en JSON Schema, y el modelo elige cuándo invocarla. La diferencia es que MCP estandariza ese anuncio para que no dependa del proveedor del modelo ni de la aplicación que lo usa.

Por qué importa el giro de Pi

El caso de Pi es instructivo porque no es el único: varias herramientas de agentes empezaron desconfiando de MCP y terminaron adoptándolo. Earendil llegó a publicar, según su propio relato en el blog de la compañía, una declaración explícita de que Pi no soportaría el protocolo, y uno de sus ingenieros escribió un post entero explicando por qué.

La razón del rechazo original no era ideológica. El problema técnico real era la composición: encadenar el resultado de una herramienta MCP como entrada de otra obligaba al modelo a leer, copiar y volver a escribir datos completos dentro del contexto de la conversación, así el dato pesara cien líneas o cien mil. Cada paso intermedio costaba tokens, y muchos servidores MCP devolvían texto plano pensado para que un humano lo leyera, no datos estructurados pensados para que otro programa los procesara.

Lo que cambió, según Earendil, no fue solo el protocolo: fue notar que la infraestructura que MCP necesitaba (carga diferida de herramientas, mensajes de sistema a mitad de conversación, metadatos por herramienta para modelos con niveles de razonamiento variables) era útil de por sí, más allá de MCP. En vez de tratar el protocolo como un agregado externo, Earendil rediseñó Pi para que esas primitivas fueran parte del núcleo, y ahí sí MCP encajaba sin fricción.

Earendil no es el único caso. Codex, el asistente de OpenAI, expone un mecanismo equivalente para componer llamadas a herramientas con código, y varios harnesses de agentes convergen en la misma idea: dejar que el modelo escriba la lógica de combinación en vez de ejecutar un plan fijo de llamadas.

💭 Clave: Codemode no reemplaza a MCP, lo complementa. MCP define cómo un cliente descubre y llama herramientas; Codemode define cómo ese cliente combina varias llamadas con lógica propia sin gastar contexto en cada paso intermedio.

Cómo funciona MCP por dentro

Las primitivas de Model Context Protocol son tres: tools (acciones que el modelo puede invocar, como leer un archivo o llamar a una API), resources (datos que el cliente puede exponer al modelo, como el contenido de un documento) y prompts (plantillas reutilizables que el servidor sugiere para tareas frecuentes). Un servidor puede exponer cualquier combinación de las tres.

La conexión sigue un patrón cliente-servidor clásico sobre JSON-RPC 2.0. Al arrancar, el cliente envía un mensaje initialize con las capacidades que soporta; el servidor responde con las suyas y la versión de protocolo que habla. Esa negociación de capacidades es la razón por la que un cliente nuevo puede seguir hablando con un servidor viejo: si una función no está en la lista de capacidades del otro lado, simplemente no se usa.

El transporte también es parte del estándar. Para un servidor que corre en la misma máquina que el cliente, como el ejemplo de sistema de archivos de este artículo, MCP usa stdio: el servidor es un proceso hijo y los mensajes viajan por su entrada y salida estándar. Para un servidor remoto, la especificación define transporte por HTTP con streaming (Server-Sent Events o streamable HTTP), que permite que el servidor viva en otra máquina sin cambiar ni una línea del protocolo de mensajes.

sequenceDiagram
participant C as Cliente MCP
participant S as Servidor MCP
C->>S: initialize
S-->>C: capacidades soportadas
C->>S: tools/list
S-->>C: lista de herramientas
C->>S: tools/call clima_actual
S-->>C: resultado estructurado
Note over C,S: la conexion persiste toda la sesion

Una vez conectado, el cliente pide tools/list para saber qué puede hacer el servidor y arma, con esa respuesta, la lista de funciones que le muestra al modelo. Cuando el modelo decide usar una, el cliente traduce esa decisión en un mensaje tools/call y le devuelve al modelo lo que el servidor respondió.

Ejemplos prácticos

Así se ve un servidor MCP mínimo en Node.js, usando el SDK oficial:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "clima-latam", version: "1.0.0" });

server.registerTool(
  "clima_actual",
  {
    title: "Clima actual",
    description: "Devuelve la temperatura actual de una ciudad de LATAM",
    inputSchema: { ciudad: z.string() },
  },
  async ({ ciudad }) => ({
    content: [{ type: "text", text: `En ${ciudad} hace 24 grados y cielo despejado.` }],
  })
);

const transport = new StdioServerTransport();
await server.connect(transport);

Este código registra una herramienta llamada clima_actual que cualquier cliente MCP (Pi, Claude Desktop, Zed) descubre automáticamente al conectarse. Cuando el cliente pide tools/list, el servidor responde algo como esto:

{
  "tools": [
    {
      "name": "clima_actual",
      "description": "Devuelve la temperatura actual de una ciudad de LATAM",
      "inputSchema": { "type": "object", "properties": { "ciudad": { "type": "string" } } }
    }
  ]
}

A partir de esa respuesta, el modelo ya sabe que existe clima_actual, qué parámetro espera y qué hace, sin que nadie haya escrito un prompt describiéndola a mano. Del lado del cliente, invocarla es un mensaje JSON-RPC como este:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": { "name": "clima_actual", "arguments": { "ciudad": "Bogotá" } }
}

El servidor responde con el resultado dentro de content, listo para que el cliente se lo muestre al modelo como si fuera la salida de cualquier otra función.

Cómo empezar

Para probar MCP sin escribir un servidor propio, el SDK oficial incluye servidores de referencia. Necesitás Node.js 18 o superior instalado; el comando siguiente corre igual en Windows (PowerShell o cmd), macOS y Linux porque usa npx:

npx -y @modelcontextprotocol/server-filesystem /ruta/a/tu/proyecto

Para que Claude Desktop lo use, agregá esto a su archivo de configuración (claude_desktop_config.json):

{
  "mcpServers": {
    "archivos": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/ruta/a/tu/proyecto"]
    }
  }
}

Para confirmar que el servidor quedó cargado, abrí Claude Desktop y fijate el ícono de herramientas en la caja de mensaje: al hacer clic debería listar archivos con la herramienta de lectura de archivos disponible. Si no aparece, revisá los logs (~/Library/Logs/Claude/ en macOS, %APPDATA%\Claude\logs en Windows) para ver el error exacto de arranque del servidor.

Casos de uso reales

El ejemplo más concreto de por qué Pi integró MCP y Codemode juntos es la combinación con otras herramientas de la propia empresa. Earendil describe, en el mismo post, un flujo donde Pi usa Codemode para combinar un servidor MCP de Linear con Jev, su motor de clasificación, para encontrar los comentarios más frustrados en un rastreador de incidencias, todo dentro de una sola sesión y sin que cada paso intermedio consuma contexto.

Fuera de Pi, el patrón se repite: editores como Zed y Cursor exponen conectores MCP para que el modelo lea el repositorio abierto, entornos como Claude Desktop lo usan para conectar Google Drive o una base de datos Postgres local, y equipos internos escriben servidores propios para exponer sistemas legacy (un CRM, un ticketing interno) sin construir un chatbot a medida para cada uno.

La lista de servidores MCP ya publicados incluye conectores para GitHub, Google Drive, Slack, Postgres y Sentry, entre decenas más catalogados en el repositorio oficial. Un equipo que ya tiene uno de esos servicios integrado no necesita escribir nada: instala el servidor correspondiente y el cliente descubre sus herramientas al conectarse.

Tabla comparativa: MCP frente a otras formas de conectar herramientas

Errores comunes y buenas prácticas

El error más frecuente es conectar demasiados servidores MCP a la vez y volcar todas sus herramientas en el contexto del modelo sin filtrar. Cada herramienta agrega su descripción y su esquema de parámetros al prompt del sistema, así que diez servidores con diez herramientas cada uno son cien definiciones compitiendo por la atención del modelo antes de que responda una sola palabra. La solución es cargar herramientas de forma diferida: mostrarle al modelo solo las de los servidores relevantes para la tarea actual.

El segundo error es de confianza: un servidor MCP corre con los permisos que el cliente le da, y no todos los servidores publicados son auditados. Instalar un servidor de un repositorio desconocido y darle acceso de escritura al sistema de archivos completo es la misma decisión que instalar una extensión de navegador sin revisar qué permisos pide.

El tercer error es devolver texto plano donde correspondería una estructura de datos. Muchos servidores MCP se escribieron pensando en harnesses que solo insertan texto en el prompt, así que optimizan para que ese texto sea corto en vez de que sea estructurado. Earendil lo resume comparando el objetivo con OpenAPI: las herramientas deberían devolver datos estructurados y ser descubribles por su documentación, no texto que el modelo tiene que volver a interpretar.

El cuarto error es no versionar el propio servidor. Si cambiás el nombre de un parámetro o el formato de la respuesta de una herramienta, cualquier cliente que ya la memorizó dentro de una conversación larga puede fallar de forma silenciosa. Tratar el esquema de una tool como un contrato público, con cambios aditivos en vez de rupturas, evita ese problema.

Profundizando: cómo escala MCP con Codemode

La especificación de Model Context Protocol define capacidades que cliente y servidor negocian al conectarse, lo que permite versionar el protocolo sin romper integraciones existentes. Pero la negociación de capacidades no resuelve el problema de composición: si un modelo necesita combinar el resultado de tres herramientas en un cálculo, tradicionalmente cada resultado intermedio pasa por el contexto de la conversación.

Codemode ataca ese problema desde otro ángulo: en vez de que el modelo orqueste llamada por llamada, escribe código JavaScript que las combina, y ese código corre en un sandbox del lado del cliente, no del lado donde corren las herramientas, que suele ser menos confiable. Como Codemode corre en el mismo proceso que el harness, su estado queda en la transcripción de la sesión en lugar de escribirse a disco, y como el sandbox puede compilarse a WASM, aporta aislamiento sin necesitar una máquina virtual completa.

flowchart TD
A["Agente o modelo de lenguaje"] --> B["Codemode: sandbox JavaScript"]
B --> C["Servidor MCP: Linear"]
B --> D["Servidor MCP: Jev"]
C --> E[("Resultado combinado")]
D --> E
subgraph Cliente["Pi u otro harness de agentes"]
B
C
D
end

Otro cambio reciente en la especificación es la carga diferida de herramientas: en vez de anunciar todas las tools al conectarse, un servidor puede exponer solo un subconjunto inicial y revelar el resto según el contexto de la conversación. Es la misma idea que resolvió el problema de contexto que motivó el rechazo original de Pi, ahora convertida en parte del protocolo.

El resultado práctico es que un agente puede pedirle a Codemode que use varios servidores MCP a la vez sin que cada paso intermedio cueste tokens de contexto: el código que los combina vive fuera de la conversación, y solo el resultado final vuelve al modelo.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: instalá el servidor de referencia @modelcontextprotocol/server-filesystem con el comando de la sección anterior y conectalo a un cliente MCP que ya tengas instalado para ver la lista de herramientas descubrirse sola.

Preguntas frecuentes

¿Qué diferencia a MCP de una API REST tradicional?

Una API REST está pensada para que un desarrollador la integre a mano, leyendo su documentación una vez. MCP está pensado para que un cliente descubra las herramientas de un servidor en tiempo de ejecución y se las muestre al modelo sin que nadie escriba código de integración por adelantado.

¿Necesito saber JavaScript para usar Codemode con MCP?

Para usarlo desde un cliente como Pi, no: el propio modelo escribe el código que combina las herramientas. Para escribir un servidor MCP propio sí conviene conocer al menos un lenguaje con soporte del SDK oficial, como JavaScript, Python o Java.

¿MCP es exclusivo de Claude?

No. Es un protocolo abierto: cualquier cliente, como Pi, Zed, Cursor o VS Code, puede implementarlo, y cualquier servidor MCP funciona con cualquiera de esos clientes sin cambios.

¿Un servidor MCP puede acceder a mi sistema de archivos sin permiso?

Solo si el cliente se lo permite. El servidor de referencia de sistema de archivos, por ejemplo, se limita a la carpeta que le pasás como argumento al arrancarlo; ese límite lo define quien configura el cliente, no el protocolo en sí.

¿Por qué Pi rechazó MCP al principio y qué le hizo cambiar de opinión?

Según Earendil, el rechazo original apuntaba a que MCP era difícil de componer y muchos servidores devolvían texto pensado para humanos. El cambio llegó cuando notaron que la infraestructura necesaria para resolver eso, como la carga diferida de herramientas y los metadatos por herramienta, también mejoraba el resto de Pi, así que integraron MCP directamente en el núcleo en vez de dejarlo como una extensión aparte.

¿Qué es Codemode y en qué se diferencia de un servidor MCP común?

Un servidor MCP expone herramientas individuales. Codemode es un sandbox que corre del lado del cliente y le permite al modelo escribir código que combina varias de esas herramientas en una sola operación, sin gastar contexto en cada paso intermedio.

Referencias

• Earendil: «You Said No MCP!»: el post original donde la empresa explica por qué integró MCP y Codemode en Pi.
• Model Context Protocol: documentación oficial: especificación completa del protocolo, primitivas y SDKs.
• Model Context Protocol en GitHub: repositorios del SDK oficial y servidores de referencia.
• Anthropic: anuncio oficial de Model Context Protocol: publicación original donde Anthropic presentó el protocolo como estándar abierto.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de BoliviaInteligente en Unsplash