Diagrama de arquitectura MCP: hosts, clientes, servidores y transportes

Tu agente de código lee el repositorio, comprueba la compilación y abre incidencias en tu gestor de tareas. Un diagrama típico de ese montaje muestra una sola caja con la etiqueta «MCP» entre el modelo y las herramientas. Luego un revisor de seguridad pregunta qué proceso puede leer tu directorio personal, qué token llega al gestor de tareas y quién aprobó la llamada que creó una incidencia. La caja no tiene respuesta.

El Model Context Protocol (MCP) tiene una arquitectura precisa, y su revisión 2026-07-28 cambió una parte. Este artículo cubre los participantes, las capas del protocolo, los transportes, las funciones, una llamada a una herramienta, la autorización remota y los límites de confianza, con un diagrama que puedes copiar.

Hosts, clientes y servidores

Antes de MCP, cada aplicación de IA necesitaba su propio adaptador para cada herramienta: cinco aplicaciones y veinte herramientas suponían hasta 100 integraciones. Con MCP, 25 implementaciones (un cliente por aplicación, un servidor por herramienta) cubren todas las combinaciones.

Un host crea un cliente por servidor, y cada cliente habla con exactamente un servidor. El modelo nunca llama a un servidor por sí mismo: pide una llamada a una herramienta, y el host decide si la ejecuta y qué cliente la envía. Los servidores permanecen aislados: no deberían ver toda la conversación ni verse entre sí.

Dos capas y qué cambió 2026-07-28

La capa de datos es JSON-RPC 2.0: peticiones (con un id que nunca es nulo), resultados, errores y notificaciones unidireccionales. La capa de transporte mueve esos mensajes y se ocupa del encuadre, la cancelación y la autorización.

La especificación 2026-07-28, publicada el 28 de julio de 2026, hizo que MCP no tuviera estado. Las revisiones anteriores abrían cada conexión con un handshake initialize que fijaba la versión y las capacidades, y los servidores HTTP podían fijar una sesión con Mcp-Session-Id. Ahora cada petición lleva su versión de protocolo y las capacidades del cliente en _meta, de modo que puede llegar a cualquier instancia del servidor detrás de un balanceador de carga round-robin sencillo.

Los servidores creados con SDK antiguos siguen esperando el handshake, así que los clientes de ambas épocas sondean primero y recurren a initialize. Un cliente que solo habla 2026-07-28 no puede usar un servidor exclusivamente heredado. El registro de cambios enumera cada cambio incompatible.

Transportes: stdio y Streamable HTTP

Streamable HTTP sustituyó al transporte HTTP+SSE (un flujo GET más un endpoint POST aparte) en 2025-03-26; HTTP+SSE está ahora formalmente obsoleto. Las pasarelas pueden enrutar y limitar la tasa según Mcp-Method y Mcp-Name sin analizar los cuerpos, y los servidores rechazan las peticiones cuyas cabeceras contradicen el cuerpo. Los servidores HTTP deben validar la cabecera Origin contra el DNS rebinding, y los locales deberían enlazarse a 127.0.0.1.

Funciones del servidor y del cliente

El modo de formulario de elicitation nunca debe pedir contraseñas, claves de API ni tokens; el modo URL envía al usuario a una página fuera del cliente. Sampling, roots y el registro de logs del servidor quedaron obsoletos en 2026-07-28 y no pueden eliminarse antes de la primera revisión publicada a partir del 28 de julio de 2027.

Una llamada a una herramienta, paso a paso

El modelo abre una incidencia a través de un servidor remoto:

1. Opcionalmente, el cliente llama a server/discover para obtener versiones y capacidades.
2. El cliente llama a tools/list. El host fusiona las listas de todos los servidores, antepone un prefijo a los nombres que colisionan y se las entrega al modelo.
3. El modelo pide create_issue. El host muestra la llamada y el usuario la aprueba.
4. El cliente envía tools/call, que se muestra a continuación.
5. Si el servidor necesita una confirmación, devuelve input_required con una solicitud de elicitation. El cliente pregunta al usuario y reintenta con la respuesta y el requestState opaco del servidor.
6. El resultado llega como complete. Un fallo de la herramienta establece isError: true, para que el modelo pueda corregirse.
7. En un flujo subscriptions/listen, notifications/tools/list_changed indica al cliente que vuelva a listar las herramientas.

POST /mcp HTTP/1.1
Host: mcp.tracker.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "create_issue",
  "arguments": {"title": "Login fails on Safari"},
  "_meta": {"io.modelcontextprotocol/protocolVersion": "2026-07-28",
   "io.modelcontextprotocol/clientInfo": {"name": "my-ide", "version": "1.4.0"},
   "io.modelcontextprotocol/clientCapabilities": {"elicitation": {}}}}}

{"jsonrpc": "2.0", "id": 7, "result": {"resultType": "complete",
 "content": [{"type": "text", "text": "Created issue #482"}], "isError": false}}

Servidores remotos y autorización

Un servidor MCP remoto es un servidor de recursos OAuth; sus tokens vienen de un servidor de autorización operado por el mismo proveedor o por un proveedor de identidad aparte. En una primera conexión:

1. El cliente llama sin token y recibe 401, normalmente con una cabecera WWW-Authenticate que apunta a los metadatos del recurso protegido del servidor (RFC 9728).
2. Ese documento, o /.well-known/oauth-protected-resource como alternativa, nombra el servidor de autorización, cuyos metadatos lee el cliente; se detiene si no se anuncia PKCE.
3. El cliente usa un ID de cliente preregistrado, un Client ID Metadata Document (una URL HTTPS como ID de cliente) o el registro dinámico de clientes, que 2026-07-28 declara obsoleto.
4. El cliente ejecuta el flujo de código de autorización con PKCE (S256) y un parámetro resource que nombra el servidor MCP (RFC 8707). El usuario inicia sesión y da su consentimiento en el navegador, y el cliente comprueba el iss de la respuesta (RFC 9207).
5. Cada petición lleva Authorization: Bearer. Un 403 con insufficient_scope activa la autorización escalonada (step-up).

El servidor solo acepta tokens emitidos para él y nunca los reenvía: las llamadas a una API ascendente usan un token distinto. El diagrama del flujo OAuth 2.0 explica PKCE, y la especificación de autorización contiene todas las reglas, basadas en el borrador de OAuth 2.1.

Dónde están los límites de confianza

El transporte stdio no es un sandbox: la guía de seguridad de servidores locales de MCP dice que un servidor stdio se ejecuta con los privilegios del cliente, y que el aislamiento depende del host y de quien opera la máquina. Un handle de estado emitido por un servidor sin estado tampoco es una credencial; vincúlalo al usuario autenticado. El diagrama de flujo de datos para modelado de amenazas muestra cómo recorrer esos límites con STRIDE.

El diagrama de arquitectura MCP

Cómo leerlo:

• El marco verde es un dominio de confianza: el host, sus tres clientes y los dos servidores stdio se ejecutan como el usuario del sistema operativo del desarrollador.
• Un cliente por servidor. Los clientes 1 y 2 usan stdin y stdout; el cliente 3 usa Streamable HTTP.
• Las aristas grises desde el modelo son llamadas a herramientas que el host enruta; los servidores nunca llegan directamente al modelo.
• El azul cruza la red con un bearer token. El violeta discontinuo es el flujo OAuth, que solo se ejecuta cuando el cliente no tiene un token válido.
• El verde azulado es el servidor remoto que llama a su API con su propio token: sin reenvío.
• El bloque Markdown resume la revisión 2026-07-28.

Cómo dibujar con claridad diagramas de arquitectura MCP

• Un cliente por servidor. Una sola caja «MCP» oculta lo que puede ver cada servidor.
• Etiqueta las aristas con el transporte y la carga útil: stdin y stdout, un POST con bearer token, un flujo OAuth, nombres de herramientas de ejemplo.
• Dibuja los límites de confianza como marcos: la máquina, el host, cada proveedor. Marca los servidores aislados en un sandbox.
• Da al servidor de autorización y a las API ascendentes sus propios nodos, para que se vean las fuentes de tokens y la regla de no reenvío.
• Indica la revisión del protocolo. Un diagrama de 2026-07-28 no tiene handshake ni IDs de sesión.
• Deja fuera los detalles internos de los SDK, las listas completas de herramientas y la infraestructura del proveedor del modelo.

El diagrama de arquitectura de agentes de IA cubre el bucle del agente alrededor de estas llamadas.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade un Marco del paquete Básico para la máquina del desarrollador y, dentro, un Límite del contenedor del paquete C4 Model para el host.
3. En el límite, añade un Modelo del paquete ML y tres nodos Componente del paquete C4 Model para los clientes, con la tecnología stdio, stdio y Streamable HTTP.
4. Añade dos nodos Contenedor del paquete C4 Model para los servidores locales, conectados con aristas «stdin / stdout», y una Persona del mismo paquete conectada al modelo.
5. Fuera del marco, añade un Límite del sistema del paquete C4 Model que contenga un Contenedor para el servidor remoto, un Sistema externo para su API y un Proveedor de identidad del paquete Seguridad, y luego dibuja las aristas del bearer token, del OAuth discontinuo y de «own token».
6. Añade un bloque Markdown del paquete Básico con los datos del protocolo, y notas de Texto de Básico para los límites.

Ninguna herramienta gratuita lee los archivos de configuración de clientes MCP, así que dibuja los servidores tú mismo o pega un diagrama de flujo de Mermaid, como el de la especificación MCP, en la herramienta de Mermaid a diagrama editable.

En el momento de escribir esto (noviembre de 2026), Archboard es en sí mismo un servidor MCP remoto en https://getarchboard.app/mcp: Streamable HTTP, OAuth 2.1 desde su propio servidor de autorización con PKCE (S256) y esa URL como indicador de recurso, y registro de clientes mediante Client ID Metadata Document o registro dinámico de clientes. La documentación del servidor MCP enumera sus herramientas, y la página de agentes de IA muestra cómo conectar tu app.

El ejemplo usa 14 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Cuál es la diferencia entre un host, un cliente y un servidor MCP? El host es la aplicación de IA, como un IDE. Crea un cliente por servidor, y cada cliente mantiene una conexión dedicada con un servidor, que expone herramientas, recursos y prompts.

¿MCP no tiene estado ahora? Sí, desde la revisión 2026-07-28: sin handshake initialize, sin ID de sesión, y cada petición lleva su propia versión y capacidades. Los servidores con revisiones anteriores siguen usando el handshake.

¿Qué transportes admite MCP? Dos estándar: stdio para servidores locales y Streamable HTTP para servidores remotos. HTTP+SSE está obsoleto, y los transportes personalizados deben conservar el formato de mensajes JSON-RPC.

¿Los servidores MCP locales necesitan OAuth? No. La especificación dice que los servidores stdio deberían tomar las credenciales del entorno. Da a cada uno un token de alcance limitado y aísla los servidores de terceros en un sandbox.

¿Qué es el token passthrough en MCP? Un servidor MCP que acepta un token que no se emitió para él, o que reenvía el token del cliente a otra API. La especificación lo prohíbe; las llamadas ascendentes necesitan el token propio del servidor.

Empieza gratis — un puesto, sin tarjeta de crédito.