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

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

Toda arquitectura MCP contiene tres componentes principales, en torno a los cuales se construye: un host, un cliente y un servidor. Con frecuencia, se describe el marco de comunicación del MCP como compuesto por una capa de datos y una capa de transporte. La capa de datos es el conjunto de reglas que determinan el formato de los mensajes (las solicitudes MCP se envían en JSON-RPC 2.0). La capa de transporte lleva esos mensajes y utiliza Streaming HTTP para las conexiones externas.

La arquitectura 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 MCP permite a los LLM descubrir qué herramientas están disponibles y ejecutar flujos de trabajo, todo ello sin necesidad de actualizaciones periódicas en el lado del cliente.

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

Desde su presentación por parte de Anthropic, la arquitectura MCP se ha generalizado en los flujos de trabajo de IA. Esto se debe en gran medida a que sustituye sistemas que requieren más mantenimiento, como los basados en múltiples conexiones de API, sin sacrificar el rendimiento. Como toda la funcionalidad disponible se encuentra tras el servidor MCP, solo se necesita una conexión, y las actualizaciones y novedades están disponibles de inmediato para la aplicación cliente.

El MCP proporciona a los LLM un medio para descubrir y llamar a las herramientas, los prompts y los recursos de los que disponen, ya sea en el sistema local de la aplicación host o a través de un proveedor externo.

En el caso de las herramientas, que dan acceso a funcionalidades externas, el descubrimiento consiste en que el host realiza una llamada tools/list al servidor MCP para averiguar qué herramientas están disponibles. A continuación, 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 siguen un proceso similar.

Diagrama de los componentes de la arquitectura 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 después 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 y en la que las funcionalidades externas a la aplicación debían llamarse mediante conexiones dedicadas y solicitudes con un formato preciso.

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 formula una pregunta a través de la interfaz de chat. A continuación, el componente orquestador del host añade contexto a la pregunta e indica al LLM qué primitivas 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. El 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 resulta útil, ya que 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 utilizará 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 utilizar la herramienta basada en IA. Desde el punto de vista arquitectónico, 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, básicamente, funcionalidades de software externas. Si se piensa en un enfoque tradicional basado en API, una aplicación de analítica web podría obtener datos mediante una solicitud con formato a un servidor externo. En la arquitectura MCP, toda la funcionalidad de terceros de un proveedor está disponible a través de una única conexión, y las solicitudes se crean según 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 disponibles para el host. Si el host consulta la base de datos, por ejemplo, con una búsqueda SQL generada por un LLM, 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 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 cabe 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 su mantenimiento corresponde al proveedor del MCP, no al cliente.

La capa de datos de la arquitectura MCP es el conjunto de reglas que definen el formato de las solicitudes, las respuestas y las notificaciones. El lenguaje estándar de los mensajes es JSON-RPC.

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

Diagrama de la capa de datos del 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 concretos.
Dar al LLM la opción de realizar una búsqueda: En un sistema agéntico, el host añade 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 su mayoría son funcionalidades de aplicaciones externas, suelen seleccionarlas el LLM o el host. Los recursos y los prompts suelen solicitarse a petición del usuario o por parte del host.

Este es el aspecto de 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 las 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 ser 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” indica al servidor MCP que se trata de una llamada a una herramienta, “name” especifica qué herramienta llamar y “arguments” proporciona las entradas necesarias.

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.

El MCP tiene dos vías de transporte:

Entrada/salida estándar: Se utiliza 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 de forma externa a 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 Server-Sent Events (SSE), un canal de «escucha» persistente que le permite devolver varios mensajes a lo largo del tiempo.

La arquitectura MCP multiinquilino es un tipo de implementación que puede dar servicio a varios usuarios (inquilinos) simultáneamente.

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, proporcionar acceso a un único servidor compartido o situar un conjunto de servidores detrás de una puerta de enlace central. Cuando se utiliza una puerta de enlace, esta enruta las solicitudes a los puntos de conexión correctos según la identidad del usuario o la naturaleza de la solicitud.

Funciona según el mismo principio básico que la arquitectura 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 es en la práctica una solicitud MCP de principio a fin? Hay ocho etapas principales, cada una de las cuales implica un componente distinto de la arquitectura.

Diagrama de flujo de una solicitud 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í es una llamada a una herramienta MCP en la práctica, siguiendo 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) utiliza 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 un 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 pertinentes 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: Medium. 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 devuelve el resultado al cliente MCP, que lo pasa al host. El host lo añade a la información que se proporciona al LLM.
Generación de la respuesta: El LLM utiliza el resultado para generar una respuesta para el usuario, como «He creado una tarea para revisar el borrador con prioridad media».

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

Al proporcionar a una aplicación host una única conexión por cada proveedor de funcionalidades o recurso interno, el MCP ayuda a resolver el problema de una entrada de contexto sobrecargada (con todas las API enumeradas) o de unos scripts de aplicación basados en API con capacidades limitadas.

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, basta con que actualice el servidor MCP. No es necesario modificar el código en la aplicación host.

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

La arquitectura 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 llegar a exponer un gran número de herramientas a un modelo de IA, lo que puede aumentar el potencial de problemas de seguridad (el radio de impacto).
Fugas de datos accidentales: Las implementaciones mal configuradas pueden provocar que información confidencial, como claves de API o credenciales de bases de datos, se transmita a un LLM.
Manipulación del sistema local: Al igual que cualquier otra aplicación, los servidores MCP locales son vulnerables a problemas del sistema local, como los scripts maliciosos, con el problema añadido de que pueden tener efectos perjudiciales en cadena sobre los sistemas de IA agéntica.

Ninguno de estos problemas es insalvable. A menudo, basta con medidas consolidadas para garantizar la seguridad del sistema. Medidas como contar con intervención humana en el proceso, aplicar controles estrictos sobre los datos confidenciales y protegerse frente a ataques al servidor son prácticas habituales.

El 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 de los desarrolladores.

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

Además, será necesario reforzar las salvaguardas de seguridad a medida que se implementen esas funcionalidades agénticas, así como contar con una arquitectura escalable, especialmente en la capa de transporte, conforme los sistemas de IA se vuelvan más amplios y complejos.

¿Qué es la arquitectura MCP?

Componentes de la arquitectura MCP: hosts, clientes y servidores

Host

Cliente

Servidor

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

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

¿Qué es la arquitectura MCP multiinquilino?

Diagrama de la arquitectura MCP: recorrido paso a paso

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

¿Es segura la arquitectura MCP?

¿Qué depara el futuro a la arquitectura MCP?