Arquitectura de MCP: análisis técnico completo con diagramas

La arquitectura de MCP es el conjunto fundamental de componentes y reglas de comunicación que hacen posible MCP (Model Context Protocol). MCP es un estándar de código abierto, y la arquitectura de MCP es la infraestructura subyacente sobre la que funciona.

Toda arquitectura de MCP contiene tres componentes principales y se construye en torno a ellos: un host, un cliente y un servidor. El marco de comunicación de MCP suele describirse como compuesto por una capa de datos y una capa de transporte. La capa de datos es el conjunto de reglas que define cómo se formatean los mensajes (las solicitudes de MCP se envían en JSON-RPC 2.0). La capa de transporte se encarga de llevar esos mensajes y usa Streaming HTTP para las conexiones externas.

La arquitectura de MCP es un marco de servidor que implementa el Model Context Protocol, un estándar abierto para conectar modelos de IA con herramientas, recursos como bases de datos y prompts que amplían el contexto de entrada. En conjunto, se denominan “primitivas”. En última instancia, la arquitectura de MCP permite que los LLM descubran qué herramientas están disponibles y ejecuten flujos de trabajo, todo sin necesidad de actualizaciones periódicas del lado del cliente.

Diagrama de la arquitectura de MCP: una aplicación de IA intercambia solicitudes con un servidor MCP, que proporciona herramientas, recursos y prompts.

Desde que Anthropic la presentó, la arquitectura de MCP se ha vuelto muy común en los flujos de trabajo de IA. Esto se debe en gran medida a que reemplaza sistemas que requieren más mantenimiento, como los construidos en torno a múltiples conexiones de API, sin sacrificar el rendimiento. Como toda la funcionalidad disponible se encuentra detrás del servidor MCP, solo se requiere una conexión, y las actualizaciones y novedades están disponibles de inmediato para la aplicación cliente.

MCP ofrece a los LLM un medio para descubrir y llamar a las herramientas, los prompts y los recursos que tienen disponibles, ya sea en el sistema local de la aplicación host o desde un proveedor externo.

En el caso de las herramientas, que dan acceso a funcionalidades externas, el descubrimiento implica que el host haga una llamada tools/list al servidor MCP para averiguar qué herramientas están disponibles. Luego, el LLM (o, en algunos casos, el host) puede leer las descripciones de las herramientas disponibles y solicitarlas según sea necesario. Los prompts y los recursos usan un proceso similar.

Diagrama de los componentes de la arquitectura de MCP: un host que contiene un LLM, un orquestador y un cliente se conecta a un servidor MCP en dos pasos, primero el descubrimiento y luego las solicitudes, y el servidor MCP expone herramientas, recursos y prompts.

Esto contrasta con la arquitectura personalizada basada en API, que ha sido la norma en el desarrollo de software, en la que las funcionalidades externas a la aplicación debían llamarse mediante conexiones dedicadas con solicitudes formateadas con precisión.

La aplicación host es la plataforma central de orquestación y se conecta a un LLM. Herramientas conocidas como Perplexity y Claude Desktop pueden actuar como hosts dentro de un sistema MCP.

En un flujo de trabajo sencillo, el usuario hace una pregunta a través de la interfaz de chat. Luego, el componente orquestador del host agrega contexto a la pregunta e indica al LLM qué primitivas de MCP están disponibles, junto con una descripción de sus capacidades.

El cliente es un componente de software de la aplicación de IA. MCP proporciona una interfaz estándar para que el cliente se comunique con servidores MCP internos y externos según las instrucciones del host o del LLM. Su función es establecer una conexión, dar formato a los mensajes JSON-RPC, enviar solicitudes y recibir respuestas.

Los términos “host MCP” y “cliente MCP” a veces se usan indistintamente. Sin embargo, la distinción es útil, porque un host, como Perplexity, puede orquestar varios clientes MCP a la vez. Un flujo de trabajo de IA complejo podría requerir acceso a decenas o incluso cientos de servidores MCP distintos, y cada uno usará una conexión independiente.

Diagrama de un host MCP, como Perplexity, que orquesta tres clientes MCP, cada uno conectado a su propio servidor MCP, como una base de datos, archivos o una API externa.

El servidor expone todas las herramientas que puede usar la herramienta basada en IA. Desde una perspectiva arquitectónica, el servidor MCP interpreta la solicitud entrante y, cuando es necesario, se conecta a las primitivas solicitadas.

Los servidores MCP pueden dar acceso a tres categorías de primitivas:

Herramientas: Son, en esencia, funcionalidades de software externas. Si se considera un enfoque tradicional basado en API, una aplicación de analítica web podría obtener datos mediante una solicitud formateada a un servidor externo. En la arquitectura de MCP, toda la funcionalidad de terceros de un proveedor está disponible a través de una sola conexión, y las solicitudes se crean siguiendo reglas de formato estándar.
Recursos: Los recursos son fuentes de datos que proporcionan contexto de solo lectura. Los esquemas de bases de datos son un buen ejemplo. El servidor MCP expone las distintas fuentes de información que están disponibles para el host. Si el host consulta la base de datos, por ejemplo, con una búsqueda SQL generada por un LLM, esto se considera una solicitud de herramienta.
Prompts: Son plantillas de prompts reutilizables que ayudan a los LLM a realizar tareas específicas. Un usuario o un host llamará a un prompt en lugar de a una herramienta porque necesita instrucciones predefinidas para completar una tarea. A menudo, las tareas predefinidas de una aplicación host, como la opción de “revisar código” o “analizar datos”, se almacenan como prompts que el usuario puede seleccionar.

También vale la pena señalar que MCP y API no son tecnologías mutuamente excluyentes. El servidor MCP puede exponer llamadas a API que estén disponibles en respuesta a una solicitud de descubrimiento. La clave es que mantenerlas le corresponde al proveedor de MCP, no al cliente.

La capa de datos en la arquitectura de MCP es el conjunto de reglas que definen cómo se formatean las solicitudes, las respuestas y las notificaciones. El lenguaje estándar para los mensajes es JSON-RPC.

Toda arquitectura de MCP sigue un proceso básico de (1) inicialización y descubrimiento por parte del host, (2) respuesta del servidor MCP y (3) una llamada del host (a veces decidida por el LLM), y cada etapa representa un mensaje JSON independiente.

Diagrama de la capa de datos de MCP: un usuario envía un prompt a la aplicación host, donde el LLM trabaja con el cliente MCP; el cliente envía una solicitud al servidor MCP (herramientas, recursos, prompts) y recibe un resultado, y el host devuelve una respuesta al usuario.

Veamos cómo funciona el descubrimiento de herramientas con dos ejemplos (que también podrían aplicarse a recursos o prompts):

Descubrir herramientas antes de la generación del LLM: El host inicia el cliente MCP, que envía una solicitud tools/list (la lista de herramientas disponibles del servidor MCP). El LLM la revisa durante el proceso de generación y determina si se necesita una herramienta, un recurso o un prompt en particular.
Dar al LLM la opción de ejecutar una búsqueda: En un sistema agéntico, el host agrega una opción de descubrimiento, como search-tools, a la entrada de contexto, y el LLM puede solicitar una búsqueda si es necesario.

Las herramientas, que en general son funcionalidades de aplicaciones externas, suelen ser seleccionadas por el LLM o el host. Los recursos y los prompts suelen solicitarse a petición del usuario o del host.

Así se ve una solicitud tools/list a un servidor MCP desde una aplicación de notas imaginaria:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

En este ejemplo, “id”:101 identifica la solicitud mediante un ID para que el cliente pueda asociar las respuestas, y el campo “params” contiene información adicional sobre el cliente, como su nombre (notes-app-client) y sus capacidades.

En respuesta, el servidor MCP devolverá las definiciones de herramientas, que incluyen los nombres de las herramientas disponibles y sus detalles asociados. Por ejemplo, la lista podría incluir una herramienta add-task que permita a la aplicación de notas crear tareas en una aplicación conectada de gestión de tareas o de calendario, y asignar a cada tarea un título y una prioridad.

Así podría verse una solicitud:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

El campo “method” le indica al servidor MCP que se trata de una llamada a herramienta, “name” especifica qué herramienta llamar y “arguments” proporciona las entradas requeridas.

Si la capa de datos es el qué de la conexión entre un cliente y un servidor MCP, la capa de transporte es el cómo. Define la forma en que viajan los mensajes: el canal específico y las reglas que rigen cómo se entregan las solicitudes y las respuestas.

MCP tiene dos vías de transporte:

Entrada/salida estándar: Se usa cuando el servidor MCP se ejecuta en el mismo entorno local que la aplicación host. El cliente escribe la solicitud JSON en la entrada estándar del servidor. El servidor la lee, realiza la operación solicitada y escribe la respuesta en la salida estándar.
Streamable HTTP: Cuando el servidor MCP se ejecuta fuera de la aplicación host, el cliente MCP envía solicitudes al servidor mediante HTTP POST. El servidor responde con un único mensaje JSON o con un flujo de Server-Sent Events (SSE), un canal de “escucha” persistente que le permite devolver varios mensajes a lo largo del tiempo.

La arquitectura multiinquilino de MCP es un tipo de implementación que puede atender a varios usuarios (inquilinos) de forma simultánea.

En este caso, un inquilino puede ser una persona, un grupo de personas o una organización. La implementación puede consistir en ejecutar un servidor MCP independiente para cada inquilino, dar acceso a un único servidor compartido o colocar un conjunto de servidores detrás de una puerta de enlace central. Cuando se usa una puerta de enlace, esta enruta las solicitudes a los endpoints correctos según la identidad del usuario o la naturaleza de la solicitud.

Funciona con el mismo principio básico que la arquitectura de MCP estándar, pero las solicitudes de cada usuario operan en su propio espacio de trabajo (aunque eso implique recursos compartidos) y se autentican por separado. Es habitual en entornos empresariales, y a menudo se prefieren los recursos compartidos porque ejecutar varios servidores MCP resultaría innecesariamente costoso.

¿Cómo se ve en la práctica una solicitud de MCP de principio a fin? Hay ocho etapas principales, y cada una involucra un componente distinto de la arquitectura.

Diagrama de flujo de una solicitud de MCP de principio a fin en ocho pasos: descubrimiento de herramientas, entrada del usuario, procesamiento del modelo, selección de herramientas, solicitud, ejecución de la herramienta, resultado y generación de la respuesta.

Así se ve en la práctica una llamada a herramienta de MCP, con el ejemplo anterior de una aplicación de notas conectada a un servicio de gestión de tareas:

Descubrimiento de herramientas: La aplicación de notas (host) usa su cliente MCP para solicitar las herramientas disponibles del servidor mediante una solicitud tools/list. El servidor devuelve sus nombres, descripciones y entradas esperadas, incluidas las de la herramienta add-task. Esto puede ocurrir antes de que envíes un prompt.
Entrada del usuario: Envías una solicitud a la aplicación de notas basada en LLM a través del chatbot integrado, por ejemplo: “Crea una tarea en mi calendario para revisar mi nuevo borrador con prioridad media”.
Procesamiento del modelo: El host envía tu solicitud y las definiciones de herramientas relevantes al LLM.
Selección de herramientas: El LLM genera una solicitud de herramienta estructurada en la que especifica la herramienta y sus entradas: add-task con title: Revisar el borrador y priority: Media. El host comprueba si la acción está permitida y pasa la solicitud al cliente MCP, que envía un mensaje JSON-RPC.
Solicitud: El cliente MCP envía una solicitud tools/call a su servidor MCP.
Ejecución de la herramienta: El servidor MCP llama a la API de la aplicación de gestión de tareas para crear una nueva tarea con el título y la prioridad especificados.
Devolución del resultado: El servidor envía el resultado de vuelta al cliente MCP, que lo pasa al host. El host lo agrega a la información que se proporciona al LLM.
Generación de la respuesta: El LLM usa el resultado para generar una respuesta para el usuario, como “Creé una tarea para revisar el borrador con prioridad media”.

MCP y la arquitectura de API tradicional suelen confundirse, pero son tecnologías complementarias. MCP se diseñó específicamente para aplicaciones basadas en IA. Supera la elevada carga de mantenimiento que implica implementar y gestionar múltiples conexiones de API codificadas de forma rígida.

Al proporcionar a una aplicación host una sola conexión por proveedor de funcionalidades o recurso interno, MCP ayuda a resolver el problema de una entrada de contexto sobrecargada (con la lista de todas las API) o de scripts de aplicaciones limitados basados en API.

En cambio, los MCP pueden exponer API (o, mejor dicho, la funcionalidad que llama a las API) como parte de su lista de herramientas. Cada vez que un proveedor actualiza su aplicación y hay una nueva API, o si cambia la documentación, simplemente actualiza el servidor MCP. No se requieren cambios de código del lado de la aplicación host.

La seguridad de MCP ha sido objeto de mucho debate desde su introducción. Aunque en general se considera una tecnología segura, presenta varios riesgos de seguridad, muchos de los cuales son más notorios en implementaciones de arquitectura complejas.

La arquitectura de MCP presenta las siguientes debilidades potenciales:

Inyección de prompts: Un usuario inserta un prompt malicioso en datos externos que el modelo de IA interpreta erróneamente como una instrucción.
Acceso con privilegios excesivos: Los servidores MCP pueden exponer una gran cantidad de herramientas a un modelo de IA, lo que puede aumentar la posibilidad de problemas de seguridad (el radio de impacto).
Filtraciones accidentales de datos: Es posible que implementaciones mal configuradas provoquen que se transmita información confidencial, como claves de API o credenciales de bases de datos, a un LLM.
Manipulación del sistema local: Los servidores MCP locales son igual de vulnerables que cualquier otra aplicación a los problemas del sistema local, como los scripts maliciosos, con el problema añadido de que pueden tener efectos perjudiciales en cascada sobre los sistemas de IA agénticos.

Ninguno de estos problemas es insuperable. A menudo, basta con aplicar medidas establecidas para garantizar la seguridad del sistema. Medidas como contar con supervisión humana en el proceso, aplicar controles estrictos sobre los datos confidenciales y protegerse contra ataques a los servidores son prácticas comunes.

MCP ha demostrado ser un estándar abierto útil y popular entre los desarrolladores. Supera muchos de los problemas de las API codificadas de forma rígida en las aplicaciones basadas en LLM y reduce considerablemente la carga de programación para los desarrolladores.

De cara al futuro, es casi seguro que la arquitectura subyacente de host y servidor de MCP se mantendrá igual. Las innovaciones futuras se centrarán en capacidades agénticas avanzadas en flujos de trabajo de varios pasos.

Además, a medida que se implementen esas funcionalidades agénticas, se necesitarán salvaguardas de seguridad más sólidas, así como una arquitectura escalable, sobre todo en la capa de transporte, conforme los sistemas de IA se vuelvan más extensos y complejos.

¿Qué es la arquitectura de MCP?

Componentes de la arquitectura de MCP: hosts, clientes y servidores

Host

Cliente

Servidor

¿Qué es la capa de datos en la arquitectura de MCP?

¿Qué es la capa de transporte en la arquitectura de MCP?

¿Qué es la arquitectura multiinquilino de MCP?

Diagrama de la arquitectura de MCP: recorrido paso a paso

¿En qué se diferencia la arquitectura de MCP de la arquitectura de API tradicional?

¿Es segura la arquitectura de MCP?

¿Qué sigue para la arquitectura de MCP?