¿Qué es MCP? Model Context Protocol, JSON-RPC, agentes de IA y llamadas a herramientas

De entrada: MCP (Model Context Protocol) no es otro nombre para Function Calling, y no es un modelo. Es un protocolo abierto entre una app de IA (el Host) y procesos de herramientas externos (MCP Servers). Los mensajes son JSON-RPC 2.0. El modelo sigue hablando el Tool Calling / Function Calling de cada proveedor. El Host traduce tools/list al array tools del modelo, y luego traduce tool_calls a tools/call. Esas tres capas juntas son la forma habitual de invocar herramientas en los agentes de 2026.

Este artículo está fechado el 7 September 2026. La especificación actual es 2026-07-28: sin sesión de protocolo, sin handshake initialize, cada petición lleva _meta, y el descubrimiento de capacidades usa server/discover. El artículo de agosto Flujo de datos JSON del Agent todavía muestra el ejemplo antiguo de initialize; toma esta guía como la lectura vigente. Para «¿tengo que cambiar el código del Server?», consulta la guía de migración MCP 2026.

Qué es MCP

Model Context Protocol es un estándar abierto para que las aplicaciones de IA descubran, lean e invoquen contexto externo. Anthropic lo publicó en noviembre de 2024; la gobernanza pasó después a la Agentic AI Foundation. Especifica cómo se intercambia el contexto. No especifica qué modelo usas, cómo orquestas un agente de varios pasos ni cómo escribes la lógica de negocio.

Piensa en USB-C: el conector es estándar; si enchufas un disco, una pantalla o una fuente de alimentación, queda fuera de alcance. MCP estandariza el conector Host ↔ Server. Un sistema de archivos, GitHub, una API interna de pedidos o un validador JSON como este sitio son, todos, Servers.

Dos capas: la capa de datos es JSON-RPC 2.0 (métodos, params, códigos de error, notificaciones); la capa de transporte es cómo se mueven esas tramas JSON — stdio en la misma máquina, Streamable HTTP en remoto. Cambias el transporte y la forma del mensaje se queda. Por eso depurar MCP empieza por separar «el sobre es JSON-RPC; la carga de negocio suele ser JSON también».

Host, Client, Server

El triángulo de la especificación se confunde fácil con el «cliente / servidor» de todos los días:

• Host: la app de IA que abrió el usuario. Crea Clients, pasa los schemas de herramientas al modelo, autoriza y valida antes de ejecutar, y escribe los resultados de vuelta en el hilo.
• Client: un objeto de conexión dentro del Host. Un Server, un Client. VS Code hablando con un sistema de archivos y con Sentry son dos Clients en runtime.
• Server: el programa que sirve contexto. Puede compartir máquina con el Host (stdio) o correr en otro sitio (Streamable HTTP). «Server» es un rol, no un requisito de hostname público.

El modelo no está en ese triángulo. GPT-5.5, Claude 4.8 y Gemini 3.7 ven el array tools que tradujo el Host. No ven JSON-RPC, y no ven Mcp-Session-Id (el encabezado de sesión desapareció en 2026-07-28). «El modelo habla MCP» es marketing. En ingeniería siempre hay un Host en el medio.

Cómo leer JSON-RPC 2.0

JSON-RPC es una convención para llamadas a procedimiento remoto usando JSON — más cerca de «llamar a una función» que de REST. MCP lo eligió porque los nombres de método se mantienen estables (tools/list, tools/call), la división petición / respuesta / notificación es limpia, y todo el sobre es JSON amigable para el modelo.

Un tools/call en la especificación 2026-07-28 se ve así. Nota: sin handshake, sin encabezado de sesión. La versión y la identidad del cliente viven en _meta, así que cualquier instancia de Server puede manejar la trama.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "validate_json",
    "arguments": {
      "payload": {"orderId": "A-1001", "total": 42.5},
      "schemaId": "order.v1"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "json-toolbox-host",
        "version": "1.0.0"
      }
    }
  }
}

Una respuesta de éxito es el mismo sobre. El resultado de negocio está en result.content, a menudo type: "text", y ese texto puede ser a su vez un string JSON — protocolo fuera, payload dentro. Al depurar, empareja primero el id con la petición, y luego valida el objeto interior contra el schema.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "content": [
      {
        "type": "text",
        "text": "{\"valid\":true,\"schemaId\":\"order.v1\"}"
      }
    ]
  }
}

Los fallos usan el objeto error de JSON-RPC: code, message, data opcional. 2026-07-28 cambió «recurso no encontrado» del -32002 específico de MCP al -32602 estándar (Invalid Params). Los Clients que buscan el literal antiguo lo perderán. Las notificaciones no tienen id y no esperan respuesta — por ejemplo, un cambio en la lista de tools.

Tools, Resources, Prompts

Un Server puede exponer tres primitivas. Los agentes viven en Tools; las otras dos se saltan fácil y a menudo ahorran una ronda de adivinanzas del modelo.

Una herramienta es name, description e inputSchema. inputSchema es JSON Schema (2020-12 desde 2026-07-28; la raíz sigue debiendo ser type: "object"; se permiten oneOf / $ref / $defs). El outputSchema opcional restringe la forma del retorno. Los Hosts copian casi 1:1 el inputSchema al parameters / input_schema de la API del modelo.

{
  "name": "validate_json",
  "title": "Validate JSON",
  "description": "Check a JSON payload against a named schema. Returns valid and errors.",
  "inputSchema": {
    "type": "object",
    "additionalProperties": false,
    "properties": {
      "payload": { "type": "object", "description": "Already parsed JSON object, not a raw string" },
      "schemaId": { "type": "string", "description": "Stable schema id such as order.v1" }
    },
    "required": ["payload", "schemaId"]
  }
}

Resources encajan en «leer, luego pensar»: cargar schema://order.v1 es más barato que hacer que el modelo memorice un schema de 200 líneas en el hilo. Prompts encajan en las aperturas fijas de un equipo. Roots, Sampling y Logging están deprecados en 2026-07-28: pasa las rutas del workspace como argumentos de herramienta o URIs de recurso; los Servers no deberían pedirle una completion al Host; los logs van a stderr o OpenTelemetry.

Cómo se apila con Tool Calling

Tres nombres se reducen a uno. No son la misma capa — el artículo de flujo de datos JSON del Agent recorre cada salto. Aquí, solo el mapeo:

Function Calling es el nombre temprano de OpenAI; Tool Calling es el término genérico posterior (Claude tools, Gemini Function Calling, OpenAI Tools API). Para el desarrollador es un solo flujo: el Host envía un schema, el modelo devuelve una llamada con argumentos JSON, el Host la ejecuta y luego mete un resultado JSON de vuelta en el hilo.

MCP no sustituye esa capa. Un Host que llama funciones en el mismo proceso solo con Tool Calling sigue siendo válido. MCP hace las herramientas descubribles, entre procesos y reutilizables entre Hosts. Los agentes de empresa casi siempre apilan ambas; los scripts y las demos a menudo se saltan MCP.

Dos trampas de mapeo: las APIs de modelo a menudo dan arguments como string; el params.arguments de MCP es un objeto. Y el name de tools/list debe llegar al modelo y a tools/call sin cambios — no inventes un alias «más amigable» en el medio. Valida antes del tools/call real; ver Tool Calling y validación con JSON Schema.

Una llamada de herramienta completa

El usuario dice: «Valida este JSON de pedido con order.v1.» En 2026-07-28, el camino es:

1. Host → Server: server/discover (cacheable) para confirmar tools; o envía la siguiente petición y reintenta si hay error de versión.
2. Host → Server: tools/list devuelve ítems con inputSchema; el resultado puede llevar ttlMs / cacheScope.
3. Host → modelo: mapea la lista a tools[].parameters (sigue siendo JSON Schema).
4. Modelo → Host: tool_calls con name validate_json; arguments suele ser JSON en string.
5. El Host valida: JSON.parse, luego comprueba inputSchema. Si falla, escribe el error como resultado de tool — no toques el Server real.
6. Host → Server: tools/call con arguments objeto y la versión de protocolo en _meta.
7. Server → Host: result.content; el Host puede comprobar outputSchema otra vez.
8. Host → modelo: un string JSON con role: tool; el modelo responde al usuario o arranca otro turno de herramienta.

User natural language
    │
    ▼
Host ──JSON Schema──► LLM Tool Calling
    │                      │
    │                      ▼
    │                 arguments JSON
    ▼                      │
MCP JSON-RPC ◄──── tools/call only after validation
    │
    ▼
result JSON ──► tool message ──► model’s final answer

En transporte remoto, los encabezados HTTP deben incluir MCP-Protocol-Version, Mcp-Method y Mcp-Name, y deben coincidir con el body o el Server debería rechazar. Los balanceadores pueden enrutar por encabezados sin parsear JSON. El stdio local no lleva esos encabezados; los nombres de método JSON-RPC son los mismos.

Qué recordar de 2026-07-28

La especificación de julio es la revisión más grande desde el lanzamiento, y el 28 de julio de 2026 es la fecha de publicación final. Para «qué es MCP», quédate con la lista de abajo. Si tu Server necesita cambios de código sigue siendo el árbol de decisión del artículo de migración.

• Sin handshake, sin sesión de protocolo: initialize / initialized y Mcp-Session-Id desaparecieron. Cada petición es autocontenida. Encadena el estado de la aplicación con un basket_id explícito (o similar) como argumento normal. No esperes que el transporte te recuerde.
• El descubrimiento es server/discover: opcional, pero una llamada devuelve versiones soportadas, capabilities y serverInfo. Los resultados de lista llevan ttlMs; un stream SSE largo ya no es la única forma de enterarte de que cambiaron las tools.
• Los schemas son JSON Schema 2020-12: la raíz de entrada sigue siendo un object; se permiten composición y refs; no resuelvas automáticamente un $ref externo. Los schemas de salida ya no están limitados a object.
• Roots / Sampling / Logging están deprecados: los métodos siguen funcionando dentro de la ventana de un año. Los Servers nuevos no deberían implementar Sampling para pedirle una completion al Host.
• Extensions: Tasks y MCP Apps son extensiones oficiales, no requisitos del núcleo. El trabajo largo usa un task handle + tasks/get. No inventes tu propia sesión.

Los Hosts y Servers que siguen en 2025-11-25 siguen usando initialize. Cuando se mezclan versiones, usa el protocolVersion negociado. No envíes las tramas sin sesión de este artículo a un Server antiguo. Para qué instalar, ver rankings de MCP Server 2026.

Qué hacer ahora

1. Dibuja tres capas antes de escribir código: el Tool Calling de la API del modelo, la orquestación del Host, el MCP Server. Los scripts pueden quedarse en las dos primeras. La reutilización entre IDEs es cuando escribes un Server.
2. Usa un SDK oficial; no armes tramas JSON-RPC a mano: @modelcontextprotocol/sdk y los demás paquetes oficiales de cada lenguaje ya cubren descubrimiento, transporte y códigos de error. SSE escrito a mano o campos privados son el caso habitual de «tienes que cambiar código» en la guía de migración.
3. Escribe inputSchema como un contrato que puedas validar solo: additionalProperties: false, required, enums, topes de longitud. Los modelos omiten campos y convierten números en strings. Bloquea una vez con el mismo schema antes de ejecutar.
4. stdio en local, Streamable HTTP en remoto: la depuración personal no necesita HTTP. Acceso compartido del equipo, muchos clientes o un gateway es cuando pasas a remoto — más OAuth y mínimo privilegio.
5. Cachea listas, recorta resultados: respeta ttlMs. No vuelques stacks en crudo al modelo. Una ventana más grande no hace seguro el JSON sucio — ver ventanas de contexto de 1M tokens.
6. Comprueba los ejemplos en el navegador antes de tocar un Server en vivo: guarda inputSchema, arguments buenos / malos y retornos de muestra del Server como JSON; valida y haz Diff en este sitio. Nada se sube. El mismo hábito que al probar un contrato REST.

FAQ

Conclusiones

MCP es el conector de herramientas del agente en 2026: JSON-RPC 2.0 mueve descubrimiento e invocación entre Host y Server; el lado del modelo sigue siendo Tool Calling; JSON Schema es el contrato compartido. No es un modelo, no es un framework y no sustituye a OpenAPI. La especificación 2026-07-28 quitó las sesiones del protocolo, así que las peticiones deben ser autocontenidas. Las tres primitivas — Tools, Resources, Prompts — no cambiaron.

Esta guía solo fija las capas. La forma de los bytes en cada salto está en el artículo de flujo de datos; si un Server antiguo debe cambiar código, en el de migración; qué Servers instalar, en el de rankings. Antes de cablear nada en vivo, valida el schema y el JSON de muestra en local — puedes cambiar de modelo; los nombres de campo y required no deberían moverse.