Qué es un servidor MCP y qué no es

Conectar un modelo de lenguaje a un sistema corporativo no es una cuestión de modelos. Es una cuestión de integración. El Model Context Protocol (MCP) existe para estandarizar exactamente esa capa. Este artículo trata MCP como protocolo y no como producto: qué especifica, qué deja fuera de forma deliberada y qué casilla ocupa en una arquitectura corporativa. Todas las afirmaciones técnicas que siguen se apoyan en la especificación oficial. Las revisiones de la especificación llevan un identificador con formato AAAA-MM-DD y solo avanzan cuando entra un cambio incompatible hacia atrás. Este artículo se basa en la revisión 2025-11-25. La revisión 2026-07-28, prevista para el 28 de julio de 2026, hace el protocolo sin estado (stateless), retira el handshake initialize y el identificador de sesión, saca Tasks del núcleo a una extensión aparte y declara Roots, Sampling y Logging deprecated con una ventana de retirada de doce meses. Los detalles de sesión y primitivas que vienen a continuación cambian en esa revisión.

Antes del protocolo: un puente por cada par

Antes de MCP, conectar una aplicación de IA a una fuente de datos significaba escribir código a medida para ese par concreto de aplicación y fuente. El anuncio original lo plantea sin rodeos: cada nueva fuente de datos exige su propia implementación, lo que limita la escalabilidad de los sistemas realmente conectados. En el sector esto se abrevia como N×M — N aplicaciones, M sistemas y N×M puentes escritos a mano entre unas y otros. Esa etiqueta no es terminología oficial, pero la situación que describe sí aparece descrita en el texto oficial. El intercambio que propone MCP es sencillo: un único protocolo en lugar de integraciones dispersas, de modo que cada lado implemente el protocolo una sola vez.

Anthropic anunció MCP y lo publicó como código abierto el 25 de noviembre de 2024; lo crearon David Soria Parra y Justin Spahr-Summers. La primera entrega llegó en tres partes: la especificación y los SDK, el soporte de servidores MCP locales en las aplicaciones Claude Desktop, y un repositorio de código abierto con servidores ya hechos para sistemas como Google Drive, Slack, GitHub, Postgres y Puppeteer.

El 9 de diciembre de 2025, Anthropic donó MCP a la Agentic AI Foundation (AAIF), un fondo dirigido dentro de la Linux Foundation. La cofundaron Anthropic, Block y OpenAI, con el apoyo de Google, Microsoft, AWS, Cloudflare y Bloomberg. MCP es uno de los proyectos fundacionales, junto a goose y AGENTS.md. La estructura de mantenimiento se conservó tal cual: el consejo rector se ocupa del presupuesto, la membresía y la aprobación de nuevos proyectos, mientras que cada proyecto mantiene plena autonomía sobre su dirección técnica. Por eso, describir MCP hoy simplemente como el protocolo de Anthropic se queda corto. La formulación exacta: nació y se liberó como código abierto en Anthropic, y desde diciembre de 2025 se gobierna bajo la AAIF dentro de la Linux Foundation. La documentación oficial cita a Claude, ChatGPT, Visual Studio Code, Cursor y MCPJam entre los clientes compatibles.

Arquitectura: host, cliente, servidor

MCP sigue una arquitectura cliente-servidor y define tres papeles distintos. El host MCP es la aplicación de IA que coordina uno o varios clientes MCP — Claude Code o VS Code, por ejemplo. Un cliente MCP es el componente que mantiene la conexión con un único servidor y obtiene contexto por cuenta del host. Un servidor MCP es un programa que proporciona contexto a los clientes MCP. El detalle que cuenta en operación: el host crea un objeto cliente por cada servidor, y cada cliente mantiene una conexión dedicada con el suyo. Los servidores no se ven entre sí.

El término servidor MCP no dice nada sobre dónde se ejecuta el código; puede ser local o remoto. En la práctica, los servidores locales sobre stdio suelen atender a un solo cliente, mientras que los remotos sobre Streamable HTTP atienden a muchos. El protocolo se divide en dos capas: una capa de datos (mensajería basada en JSON-RPC 2.0, ciclo de vida, primitivas, notificaciones) y una capa de transporte (establecimiento de la conexión, framing de mensajes, autorización). MCP es un protocolo con estado. La sesión se abre con initialize, ahí se negocian las capacidades, y cliente y servidor deben coincidir en una única versión del protocolo.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": { "name": "example-host", "version": "1.0.0" }
  }
}

La especificación define dos transportes estándar: stdio y Streamable HTTP. Los clientes deberían admitir stdio siempre que sea posible, y se permiten transportes propios mientras conserven el formato de mensajes JSON-RPC y los requisitos del ciclo de vida. Streamable HTTP expone una única ruta de endpoint MCP que admite tanto POST como GET; el servidor puede transmitir las respuestas por SSE si así lo decide. El antiguo transporte HTTP+SSE de la revisión 2024-11-05 quedó sustituido por Streamable HTTP y está deprecated. Sobre HTTP, los clientes deben enviar la cabecera MCP-Protocol-Version en todas las peticiones posteriores a initialize, y el valor enviado debería ser la versión negociada durante initialize; un servidor que no recibe ninguna cabecera asume 2025-03-26. Un servidor puede emitir un MCP-Session-Id en la inicialización y esperarlo en las peticiones siguientes.

La especificación dice sin rodeos que MCP se inspira en parte en el Language Server Protocol. La analogía aguanta: LSP estandarizó la unión entre un editor y un lenguaje; MCP estandariza la unión entre una aplicación de IA y un sistema externo.

Lo que un servidor expone realmente

Los servidores exponen sus capacidades a través de tres primitivas centrales. Lo que las distingue no es lo que hacen, sino quién las controla:

• Tools — funciones que el modelo puede invocar para actuar: escribir en una base de datos, llamar a una API externa, modificar archivos. Las controla el modelo. Métodos: tools/list, tools/call.
• Resources — fuentes de datos pasivas, de solo lectura, que aportan contexto: contenido de archivos, esquemas de base de datos, respuestas de API. Las controla la aplicación. Métodos: resources/list, resources/templates/list, resources/read, resources/subscribe.
• Prompts — plantillas de interacción reutilizables y parametrizadas. Las controla el usuario; la especificación espera que se invoquen de forma explícita. Métodos: prompts/list, prompts/get.

Las entradas de las herramientas se declaran con JSON Schema. Eso permite que quien escribe el servidor confíe en el esquema y no en el modelo: la llamada entrante se valida contra el esquema antes de llegar a la lógica de negocio.

{
  "name": "get_order_status",
  "title": "Get order status",
  "description": "Returns the current status of a given order number.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "orderNumber": { "type": "string", "pattern": "^[A-Z]{2}-[0-9]{6}$" },
      "verbose": { "type": "boolean", "default": false }
    },
    "required": ["orderNumber"]
  }
}

En el lado de los recursos, cada recurso lleva un URI único y declara un tipo MIME. Más allá de los URI fijos, los servidores pueden publicar Resource Templates parametrizadas — una plantilla que recibe una ciudad y una fecha, por ejemplo. El flujo no va en una sola dirección: los clientes también exponen primitivas a los servidores. Sampling permite a un servidor pedir una completion al modelo del host (sampling/createMessage). Elicitation permite a un servidor pedir al usuario información adicional o una confirmación (elicitation/create). Roots permite a un servidor consultar el límite del sistema de archivos que se le ha concedido. Logging completa el conjunto. La primitiva Tasks, pensada para operaciones de larga duración, está marcada como experimental en la revisión actual, así que no conviene darla por fija en un plan de despliegue. Los servidores cuyas capacidades cambian pueden emitir notificaciones como notifications/tools/list_changed — pero solo si anunciaron listChanged durante initialize.

Dónde ocurre realmente la autorización

Este es el punto que más se confunde al leer. En MCP la autorización está definida a nivel de transporte y es opcional. Los transportes basados en HTTP deberían ajustarse a la especificación de autorización; los transportes STDIO no deberían seguirla y, en su lugar, deberían tomar las credenciales del entorno. Buscar un flujo OAuth dentro de un servidor stdio local es mirar la capa que no corresponde.

Sobre HTTP los papeles son inequívocos. Un servidor MCP protegido actúa como resource server de OAuth 2.1. Un cliente MCP actúa como cliente OAuth 2.1. El authorization server es una parte aparte — puede estar alojado junto al resource server o funcionar de forma completamente independiente. Esa separación es lo que sostiene la afirmación de que un servidor MCP es un límite de autorización: el servidor no emite tokens, los valida y restringe el acceso en consecuencia. Los estándares con los que esta sección declara conformidad son el borrador de OAuth 2.1, RFC 8414, RFC 7591, RFC 9728 y el borrador OAuth Client ID Metadata Documents. Aparte de eso, el mismo documento exige RFC 8707 para el parámetro resource.

Los requisitos que se traducen directamente en decisiones de despliegue:

• Los servidores MCP deben implementar RFC 9728 (Protected Resource Metadata), y los clientes deben usarlo para descubrir el authorization server.
• Los clientes deben implementar PKCE y usar el método de challenge S256 cuando sea técnicamente posible; si la compatibilidad con PKCE no puede verificarse en el campo code_challenge_methods_supported de los metadatos del authorization server, el cliente debe negarse a continuar.
• Los servidores deben validar que los access tokens se emitieron específicamente para ellos como audience prevista, y deben rechazar los tokens que no los nombren.
• Al llamar a una API upstream, el servidor MCP actúa como cliente OAuth por derecho propio y no debe reenviar el token que recibió del cliente MCP. El token passthrough es un patrón expresamente prohibido.
• Los tokens no pueden viajar en la cadena de consulta del URI; cada petición HTTP lleva una cabecera Authorization: Bearer, incluso dentro de la misma sesión lógica.
• Los identificadores de sesión no son un mecanismo de autenticación: los servidores no deben usar las sesiones para autenticar.

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="orders:read orders:write",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         error_description="Write permission required"

Los códigos de estado también están especificados: 401 cuando hace falta autorización o el token no es válido, 403 por scope insuficiente, 400 por una petición con formato no válido. Ante un 403 el servidor anuncia en la cabecera WWW-Authenticate los scopes necesarios, y el cliente puede ejecutar un flujo de autorización step-up. La minimización de scopes está oficialmente recomendada, y los nombres de scope generalistas como *, all o full-access figuran entre los antipatrones habituales en las implementaciones.

Lo que MCP no es

MCP no es un modelo. Es un estándar abierto para conectar aplicaciones de IA con sistemas externos. Dentro no hay pesos, ni motor de inferencia, ni criterio alguno sobre el comportamiento del modelo. Qué modelo ejecutes queda fuera de lo que atañe al protocolo.

MCP no es un framework de agentes. La nota oficial sobre el alcance es explícita: MCP se ocupa únicamente del protocolo de intercambio de contexto y no dicta cómo las aplicaciones de IA usan los LLM ni cómo gestionan el contexto que reciben. Planificación, control del bucle, memoria, política de reintentos — todo eso vive en tu aplicación, no en el protocolo.

MCP no es un sistema RAG. La documentación de resources lo dice directamente: las aplicaciones acceden a la información y deciden cómo usarla, ya sea seleccionando las partes relevantes, buscando con embeddings o pasándolo todo al modelo. La indexación, el chunking y la búsqueda vectorial no están definidos en ningún punto del protocolo. Son decisiones de la aplicación.

MCP no sustituye a un API gateway. Un servidor MCP no es una capa de paso transparente delante de las API upstream. El access token que se usa hacia upstream es un token distinto, emitido por el authorization server de ese lado, y el servidor no debe reenviar el que recibió. El servidor lleva su propia identidad y su propio límite de autorización. El rate limiting, las cuotas, la traducción de protocolos y el enrutado en el borde siguen siendo tarea del gateway.

La analogía oficial es buena: piensa en MCP como un puerto USB-C para aplicaciones de IA. El puerto no define qué hay al otro extremo del cable ni qué hace el dispositivo conectado con esa conexión.

Dónde encaja el servidor en un despliegue on-premise

La sección de seguridad de la especificación enumera cuatro principios: consentimiento y control del usuario, privacidad de los datos, seguridad de las herramientas y controles del sampling del LLM. La misma sección añade un matiz: MCP no puede imponer esos principios a nivel de protocolo, así que se espera que lo hagan quienes lo implementan. Ese matiz explica por sí solo por qué las decisiones de arquitectura pesan tanto aquí. La mayor parte del control no vive en el protocolo, sino en quién ejecuta el servidor y dónde se ejecuta.

Los requisitos de seguridad de la especificación hacen del alojamiento on-premise la opción natural. Los servidores que corren en local deberían escuchar solo en 127.0.0.1 y no en todas las interfaces. Los servidores que usan Streamable HTTP deben validar la cabecera Origin y devolver 403 ante un valor no válido, que es la protección frente al DNS rebinding. Se recomienda autenticación en todas las conexiones. Un servidor local es un proceso que ejecuta código en la máquina host: la especificación recomienda que el cliente lo ejecute en un sandbox con privilegios mínimos por defecto, y que el servidor que corre en local restrinja el acceso a stdio o a un canal IPC acotado, como un unix domain socket. Los clientes MCP que consultan URL de descubrimiento OAuth deberían bloquear las peticiones a rangos de IP privados y reservados, y los despliegues de cliente MCP en el lado del servidor deberían plantearse un proxy de egress — la parte que cubre el server-side request forgery, es decir, el caso en que un servidor dirige a un cliente hacia direcciones de la red interna. Los servidores proxy que usan client IDs estáticos deben obtener el consentimiento del usuario para cada cliente registrado dinámicamente — la regla que cierra el caso del confused deputy. El aislamiento de audience de los tokens ya dice lo mismo con otro vocabulario: el servidor es el límite.

Puesto todo junto, el cuadro es este. El servidor MCP es el punto por el que pasan los datos corporativos y las acciones corporativas. Aunque el modelo se ejecute en otro sitio, el servidor determina qué herramientas existen, qué recursos son legibles y con qué identidad viaja cada llamada hacia upstream. Si ese servidor está dentro de tu red y bajo tu control, todas esas decisiones quedan en un sitio que puedes auditar. La especificación señala además que las descripciones y anotaciones de las herramientas deberían tratarse como no fiables mientras no vengan de un servidor de confianza — y quien define qué es de confianza es quien traza el límite.

La forma más corta de situar MCP: la mayor parte del código que antes escribías para conectar un modelo a un sistema corporativo nunca tuvo que ver con el modelo. Tenía que ver con el descubrimiento, los esquemas, la identidad, la autorización, el formato de las respuestas excepcionales y el ciclo de vida. MCP estandariza esa parte y se mantiene al margen del resto. Por eso las preguntas de diseño de un servidor MCP no son preguntas de protocolo: qué acciones se convierten en herramientas, qué datos pasan a ser legibles como recursos y qué identidad llega a qué sistema upstream con qué scope. El protocolo aclara dónde se plantean esas preguntas. Responderlas sigue siendo trabajo de arquitectura.

Fuentes

• Model Context Protocol — specification, 2025-11-25 revision
• MCP specification — Authorization section (OAuth 2.1 roles, RFC 9728, error codes)
• MCP specification — Versioning and feature lifecycle
• MCP Blog — The 2026-07-28 MCP Specification Release Candidate
• MCP Blog — MCP joins the Agentic AI Foundation (9 December 2025)
• Anthropic — Introducing the Model Context Protocol (25 November 2024)