Un servidor MCP y una API se confunden con facilidad porque el mismo backend suele estar detrás de los dos. La API es el contrato que llama tu programa. El servidor MCP es un segundo contrato, escrito en JSON-RPC, que existe para que un host de IA pueda descubrir e invocar ese backend sin que tú escribas una integración distinta para cada modelo.

El Model Context Protocol sigue importando en 2026, pero la mayoría de los artículos describen un protocolo que ya no existe. La revisión 2026-07-28 eliminó el handshake de conexión, dejó obsoletos sampling y roots, e hizo que cada petición lleve su propia versión y capacidades. Esta guía compara un servidor MCP con una API a secas contra la especificación actual, y muestra dónde la capa se gana su coste.

01Qué es cada lado en realidad

Una API REST es un contrato entre dos programas. Sabes quién llama, escribes tú el cliente y recibes aviso en tiempo de compilación o de test cuando el contrato cambia. La forma es estable: un método HTTP, una ruta, cabeceras, un cuerpo y un código de estado.

Un servidor MCP es un programa que expone contexto y capacidades a un host de IA mediante el Model Context Protocol. La especificación define tres roles: el host es la aplicación LLM, un cliente es un conector dentro de ese host, y un servidor es el programa que aporta contexto. El host abre un cliente por servidor, así que un mismo asistente de código puede hablar a la vez con un servidor de archivos, uno de base de datos y uno de un SaaS externo.

Lo que lo cambia todo es quién elige la llamada. En una integración API, el punto de llamada es código que has revisado. En MCP, un modelo escoge una herramienta de una lista y rellena los argumentos, así que el servidor tiene que ser seguro cuando quien llama se equivoca, tiene curiosidad o actúa de forma hostil.

Llamada API       : tu código      -> endpoint fijo -> resultado con tipos
Llamada MCP       : la elige el modelo -> tools/call -> content[] + structuredContent

02Qué añade MCP sobre una API

MCP estandariza cuatro cosas que una API deja en manos de cada integrador:

• Descubrimiento. Un servidor que declara la capacidad tools debe responder a tools/list con las herramientas disponibles. Cada entrada lleva nombre, descripción e inputSchema, así que el host puede dar al modelo una lista nueva sin volver a desplegar.
• Delegación. El modelo elige la herramienta y los argumentos en tiempo de ejecución, justo lo que quieres cuando la petición del usuario es abierta y no puedes enumerar todos los caminos de antemano.
• Un cliente para cada servidor. El host implementa el protocolo una vez. A partir de ahí, una integración nueva es un servidor nuevo, no un SDK y un flujo de autenticación por proveedor.
• Una superficie de consentimiento. La especificación dice que siempre debería haber una persona en el bucle con capacidad de denegar la invocación de una herramienta, y pide al host que muestre qué herramientas están expuestas y cuándo se ejecutan.

Un listado de herramientas es una petición y una respuesta JSON-RPC pequeñas:

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

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "search_orders",
        "description": "Search orders by status for the signed-in customer",
        "inputSchema": {
          "type": "object",
          "properties": { "status": { "type": "string", "enum": ["open", "shipped", "cancelled"] } },
          "required": ["status"]
        }
      }
    ]
  }
}

Todo lo de ese bloque es texto de prompt. El nombre, la descripción y el esquema los lee un modelo, no un compilador, y por eso diseñar herramientas se parece más a escribir documentación que a escribir un SDK.

03Lo que una API sigue haciendo mejor

MCP es una fachada, así que la API conserva todas las ventajas de tener un llamador determinista:

Dos costes merecen énfasis. El primero es el contexto: cada herramienta que expones es esquema y descripción que compiten por la misma ventana de contexto que la pregunta real del usuario, y por eso hay equipos que publican servidores MCP que reducen el consumo filtrando lo que ve el modelo. El segundo es el modo de fallo: un error de API es un bug; un error de una herramienta que el modelo eligió mal es un comportamiento que tienes que diseñar.

04Cuándo es buena idea un servidor MCP

La regla práctica: añade MCP donde el modelo tenga que tomar una decisión, y conserva la API allí donde un programa ya sabe qué hacer. Envolver una API entera uno a uno es la forma más común de volver a un agente más lento, más caro y más fácil de confundir.

05Envuelve una API existente sin reescribirla

Rara vez necesitas un backend nuevo. Un servidor MCP fino traduce una llamada de herramienta en una petición API:

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": { "name": "search_orders", "arguments": { "status": "shipped" } }
}

Esa llamada corresponde a una sola petición REST:

GET /api/orders?status=shipped
Authorization: Bearer <token del usuario autenticado>

La respuesta devuelve bloques de contenido, y cualquier valor legible por máquina va en structuredContent:

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [{ "type": "text", "text": "Se encontraron 3 pedidos enviados." }],
    "structuredContent": { "orders": [ { "id": "A-1043", "status": "shipped" } ] },
    "isError": false
  }
}

Antes de publicar la capa, pasa la petición y la respuesta por el validador de JSON para confirmar que ambas formas se analizan.

Tres reglas de implementación mantienen la capa fina:

1. Mantén estables los nombres y los esquemas. Son el contrato que lee el modelo, así que renombrar un campo es un cambio incompatible aunque la API no se haya movido.
2. Pasa las credenciales de quien llama, con alcance limitado. Las herramientas que devuelve un servidor pueden variar según la autorización de la petición, así que un token con menos scopes ve una lista más pequeña en lugar de una que no puede usar.
3. Devuelve un error sobre el que el modelo pueda actuar. Un argumento inválido debe ser un resultado isError con un mensaje claro, no una lista vacía silenciosa.

06El transporte decide el modelo de despliegue

MCP separa lo que significa un mensaje de cómo viaja. La especificación define dos transportes estándar:

• stdio enmarca JSON-RPC delimitado por saltos de línea sobre los flujos estándar de un subproceso que lanza el cliente. Suele atender a un solo cliente y encaja con herramientas locales como un servidor de archivos.
• Streamable HTTP envía cada mensaje como un POST HTTP a un único endpoint MCP, y la respuesta llega como objeto JSON o como un flujo de eventos del servidor ligado a esa petición. Atiende a muchos clientes, que es lo que necesita un servidor remoto compartido.

El transporte antiguo HTTP+SSE está obsoleto en favor de Streamable HTTP. Los servidores remotos heredan además la especificación de autorización de MCP, construida sobre OAuth 2.1, así que elegir HTTP no te permite saltarte el diseño de autorización.

Un último detalle de transporte: los metadatos viajan ahora en el cuerpo del mensaje. Cada petición lleva su versión de protocolo y las capacidades del cliente en campos _meta, y el transporte Streamable HTTP puede reflejar algunos campos en cabeceras para los intermediarios. El cuerpo sigue siendo la fuente de verdad.

07El modelo de seguridad cambia

A una API la ataca quien alcanza su red. A un servidor MCP lo ataca quien alcanza su red y además quien puede influir en el texto que lee un modelo antes de llamar a una herramienta. La guía de seguridad de MCP documenta los modos de fallo, y conviene leerla antes de publicar un servidor remoto:

Los principios de la propia especificación son directos: el usuario debe consentir de forma explícita el acceso a datos y las operaciones, el host no debe reenviar datos del usuario a un servidor sin consentimiento, y las descripciones de herramientas deben tratarse como no confiables salvo que vengan de un servidor de confianza. No son eslóganes: son la diferencia entre una demo y un servicio que sobrevive al contacto con un documento hostil.

La descripción de una herramienta es un prompt escrito por otra persona.

MCP pide a quien implementa que trate las descripciones de herramientas como entrada no confiable, porque un servidor comprometido o malicioso puede usarlas para dirigir al modelo. Revisa un servidor de terceros como revisarías una dependencia, no como revisarías un endpoint REST.

08El cambio de versión es parte del trato

Las revisiones de MCP llevan fecha, no número. La última al escribir esto es 2026-07-28; la anterior ampliamente desplegada es 2025-06-18. La 2026-07-28 es un cambio incompatible para quien implementó siguiendo un artículo de blog:

• El handshake initialize desaparece. Cada petición declara su versión de protocolo y las capacidades del cliente, y el servidor la acepta o la rechaza de forma independiente. Una petición de una versión que el servidor no implementa devuelve UnsupportedProtocolVersionError con la lista de versiones admitidas.
• roots, sampling, logging y el registro dinámico de clientes quedan obsoletos desde 2026-07-28, y podrán eliminarse a partir de la siguiente revisión.
• Los servidores ya no inician peticiones JSON-RPC y los clientes ya no envían respuestas JSON-RPC. Esa sola regla saca del protocolo central la recursión al estilo sampling.

Si una guía de integración te dice que abras una sesión con estado y negocies capacidades una vez, está escrita para una revisión antigua. Fija la revisión que implementa tu servidor y muestra la lista de versiones admitidas en lugar de fallar de forma opaca.

09Errores comunes

Cuando cambie el esquema de una herramienta, compara las dos versiones con el comparador de diferencias antes de que el modelo vea el contrato nuevo, y mantén honestos los códigos REST que hay detrás con la referencia de códigos de estado HTTP.

10Fuentes

• Model Context Protocol — Specification, revisión 2026-07-28 (fecha de consulta: 2026-10-04)
• Model Context Protocol — Architecture overview (fecha de consulta: 2026-10-04)
• Model Context Protocol — Transports (fecha de consulta: 2026-10-04)
• Model Context Protocol — Versioning and Compatibility (fecha de consulta: 2026-10-04)
• Model Context Protocol — Server Features: Tools (fecha de consulta: 2026-10-04)
• Model Context Protocol — Deprecated Features (fecha de consulta: 2026-10-04)
• Model Context Protocol — Security Best Practices (fecha de consulta: 2026-10-04)
• JSON-RPC 2.0 Specification (fecha de consulta: 2026-10-04)