Servidores MCP: qué estandariza realmente el Model Context Protocol

Todas las explicaciones de MCP empiezan con la misma frase: es el USB-C de la IA. La analogía no es un invento de marketing, viene de la propia especificación, y es buena. Pero se detiene justo donde empiezan las preguntas útiles. ¿Qué entrega realmente un servidor? ¿Quién habla con quién? ¿Y qué ha retirado discretamente la última revisión de los tutoriales que está a punto de copiar?

Qué es MCP, en los términos de la especificación

La documentación oficial define MCP como un estándar de código abierto para conectar aplicaciones de IA a sistemas externos. Gracias a él, aplicaciones como Claude o ChatGPT pueden conectarse a fuentes de datos, herramientas y flujos de trabajo, lo que les permite acceder a información y realizar tareas.

Después llega la analogía que todos repiten: piense en MCP como un puerto USB-C para aplicaciones de IA. Igual que el USB-C ofrece una forma estandarizada de conectar dispositivos electrónicos, MCP ofrece una forma estandarizada de conectar aplicaciones de IA a sistemas externos.

Lo que conviene retener de esa comparación es lo que excluye. Un estándar de conector no dice nada de los dispositivos. La documentación plantea además esa misma restricción por escrito: 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 proporcionado. Si esperaba que MCP le dijera cómo construir su agente, no lo hará. Le dice cómo enchufarle cosas.

Host, cliente, servidor: tres papeles que se confunden constantemente

Aquí es donde descarrilan la mayoría de las discusiones de arquitectura, porque en el lenguaje corriente « el cliente MCP » y « la aplicación » parecen designar lo mismo. En la especificación, no:

Host MCP. La aplicación de IA que coordina y gestiona uno o varios clientes MCP. Claude Desktop y Visual Studio Code son hosts.

Cliente MCP. Un componente que mantiene una conexión con un servidor MCP y obtiene contexto de él para el host. Es un objeto de conexión dentro del host, no un software que instalen sus usuarios.

Servidor MCP. Un programa que proporciona contexto a los clientes MCP.

La relación entre los dos últimos es estrictamente de uno a uno. El host crea un cliente MCP para cada servidor MCP, y cada cliente mantiene una conexión dedicada con su servidor correspondiente. Conecte VS Code a un servidor Sentry y a un servidor de sistema de ficheros y el runtime instancia dos objetos cliente distintos. No hay ningún canal multiplexado compartido sobre el que razonar, lo que simplifica bastante la depuración.

Las tres cosas que un servidor puede exponer, y por qué importa la distinción

Las primitivas son el corazón de MCP, y equivocarse de primitiva es el error de diseño más frecuente en un primer servidor. La especificación define tres del lado del servidor:

Herramientas. Funciones ejecutables que las aplicaciones de IA pueden invocar para actuar, por ejemplo operaciones sobre ficheros, llamadas a API o consultas a bases de datos. Una herramienta hace algo.

Recursos. Fuentes de datos que aportan información contextual, por ejemplo el contenido de ficheros, registros de base de datos o respuestas de API. Un recurso se lee.

Prompts. Plantillas reutilizables que ayudan a estructurar las interacciones con los modelos de lenguaje, por ejemplo prompts de sistema o ejemplos few-shot.

El ejemplo que da la propia documentación es la mejor prueba para saber si ha elegido bien. Para un servidor que expone una base de datos, sugiere herramientas para consultarla, un recurso que contenga el esquema, y un prompt con ejemplos few-shot para usar las herramientas. Misma base, tres primitivas distintas, cada una respondiendo a una pregunta distinta. Si se sorprende exponiendo su esquema como una herramienta, esa es la señal de que ha confundido « un dato que el modelo debe leer » con « una acción que el modelo puede lanzar ».

Cada tipo de primitiva dispone de métodos de descubrimiento, y los clientes usan los métodos de listado para saber qué existe antes de usarlo. Eso es lo que hace que los listados sean dinámicos en vez de quedar fijados en el cliente al compilar.

Dos transportes, y la cuestión de seguridad que se deriva

MCP consta de dos capas: una capa de datos que define el protocolo basado en JSON-RPC, y una capa de transporte que define los mecanismos de comunicación. El protocolo usa JSON-RPC 2.0, y el mismo formato de mensaje viaja por todos los transportes, razón por la cual la elección del transporte no cambia cómo escribe sus handlers.

Transporte stdio. Usa los flujos de entrada y salida estándar para la comunicación directa entre procesos locales de la misma máquina, con rendimiento óptimo y sin sobrecarga de red.

Transporte Streamable HTTP. Usa peticiones HTTP POST para los mensajes del cliente al servidor, con Server-Sent Events opcionales para el streaming. Es el que permite la comunicación con un servidor remoto, y admite los métodos de autenticación HTTP estándar, incluidos los tokens bearer, las claves de API y las cabeceras personalizadas. La especificación recomienda usar OAuth para obtener los tokens.

Fíjese en lo que eso implica, porque rara vez se dice. Un servidor stdio no tiene autenticación propia: es un proceso que ha lanzado el host, y se ejecuta con los permisos de ese proceso. Es perfectamente razonable para un servidor de ficheros en su propio equipo, y es el modelo equivocado en cuanto ese mismo código se expone por HTTP. La documentación observa también que un servidor stdio local suele atender a un único cliente, mientras que un servidor HTTP remoto suele atender a muchos, lo que es tanto una cuestión de carga y aislamiento como de red.

Lo que la revisión 2026-07-28 dejó obsoleto

Esta es la sección que le evitará copiar un tutorial caducado, porque dos funcionalidades del lado del cliente, presentes en la mayoría del material existente sobre MCP, ya no son la vía recomendada.

El sampling está obsoleto desde la versión de protocolo 2026-07-28. Permitía a un servidor solicitar completaciones de modelo a la aplicación de IA cliente, lo que resultaba atractivo: el autor de un servidor se mantenía independiente del modelo y evitaba incorporar un SDK de LLM. La documentación dirige ahora a las nuevas implementaciones hacia una integración directa con las API de los proveedores de LLM.

El logging está obsoleto en la misma revisión, y las nuevas implementaciones deben escribir en stderr con el transporte stdio, o usar OpenTelemetry.

Lo que permanece del lado del cliente es la elicitación, que permite a un servidor solicitar información adicional al usuario. Es el mecanismo para hacer una pregunta o pedir confirmación de una acción en mitad de una operación, y es al que hay que recurrir cuando un servidor necesita una entrada que no puede deducir.

La misma revisión hace explícita además la ausencia de estado: cada petición lleva la versión del protocolo y las capacidades pertinentes en su campo meta, de modo que el servidor puede procesar cada petición por separado. Los servidores anuncian las versiones y capacidades que admiten mediante una petición de descubrimiento obligatoria, que los clientes pueden enviar antes que ninguna otra. En la práctica, un servidor MCP no necesita recordar con quién habla entre una llamada y otra, lo que hace el escalado horizontal de un servidor remoto bastante menos doloroso.

Por qué esto va más allá del protocolo

Lo estratégico no es el JSON. Es que MCP es un protocolo abierto admitido por una amplia gama de clientes y servidores, desde asistentes como Claude y ChatGPT hasta herramientas de desarrollo como Visual Studio Code y Cursor, lo que, en palabras de la documentación, permite construir una vez e integrar en todas partes.

Para una empresa, eso cambia la naturaleza de la pregunta de integración. Exponer sus sistemas internos mediante un servidor MCP no es una apuesta por el asistente de un fabricante concreto. Es el mismo trabajo rentabilizándose en cada host que hable el protocolo, hoy y mañana. El perfil de riesgo es muy distinto al de escribir un plugin a medida para un solo producto, y es la razón principal por la que MCP merece un sitio en una hoja de ruta de integración y no en una carpeta de pruebas de concepto.

Preguntas frecuentes

La definición de MCP, la analogía del USB-C, el enunciado de que MCP se ocupa únicamente del protocolo de intercambio de contexto, las definiciones de host, cliente y servidor, la relación de un cliente por servidor, las definiciones de herramientas, recursos y prompts, los dos transportes y sus propiedades, la recomendación de OAuth, la obsolescencia del sampling y del logging desde la versión de protocolo 2026-07-28, y la ausencia de estado del protocolo proceden todas de la documentación oficial del Model Context Protocol, consultada en el momento de la redacción. El protocolo se revisa: verifique con la revisión a la que apunte.

El acompañamiento de ZAX en MCP e integración de IA

Nuestro equipo construye servidores MCP que exponen sistemas internos a las aplicaciones de IA, y los integra en productos existentes.

Auditoría y encuadre. Una auditoría de IA gratuita de 30 minutos establece cuáles de sus sistemas merecen exponerse, qué primitiva encaja con cada uno, y si stdio o HTTP es el transporte adecuado para sus restricciones.

Desarrollo e integración. Diseño del servidor, modelado de las primitivas, autenticación en el transporte HTTP y pruebas de integración contra hosts reales.

Contáctenos para hablar de la exposición de sus sistemas mediante MCP.

Artículos relacionados