Si buscó "diagrama de arquitectura del protocolo de contexto de modelo" con la esperanza de encontrar algo que realmente pudiera dibujar en una pizarra y explicar a su equipo, está en el lugar adecuado. La mayoría de las explicaciones sobre MCP se quedan en "conecta la IA con herramientas" o profundizan directamente en los detalles de la especificación sin responder nunca a la pregunta arquitectónica básica: qué se comunica con qué, en qué orden y quién es responsable de cada cosa.
Este artículo le ofrece una visión a nivel de implementación. No solo definiciones.
Lo que la mayoría de los equipos aprende después de lanzar el producto
- MCP se sitúa sobre las API: estandariza cómo los LLM descubren y llaman a estas API, no las sustituye.
- La arquitectura abierta de cliente-servidor estándar significa que un host puede ejecutar varios clientes, cada uno conectándose de forma independiente a un servidor diferente.
- MCP define la interfaz de integración; el control de acceso, la gobernanza de datos y la seguridad son su responsabilidad de implementar.
Qué es el Model Context Protocol y por qué Anthropic lo introdujo
El protocolo de contexto de modelo es un protocolo abierto introducido por Anthropic en noviembre de 2024. La definición de la especificación oficial es precisa: MCP es una forma estandarizada para que las aplicaciones de IA se conecten a fuentes de datos, herramientas y sistemas externos mediante una interfaz coherente, en lugar de crear una conexión personalizada para cada uno.
Esa última parte es clave. Antes de MCP, cada equipo que conectaba un LLM a una herramienta escribía su propio adaptador. Distinta estructura, distinto enfoque de autenticación, diferente gestión de errores. Escale esto a docenas de herramientas y tendrá docenas de integraciones específicas que necesitan mantenimiento por separado. El estándar MCP existe para condensar todo eso en una única estructura de protocolo.
Anthropic lo introdujo, pero no es un producto exclusivo de Anthropic. La especificación de MCP es abierta, se mantiene públicamente y ya se ha adoptado en IDE, asistentes de programación, plataformas de IA y pilas de agentes empresariales. Para el primer trimestre de 2026, el mapa del ecosistema de protocolos de DigitalApplied identificaba MCP junto con A2A, ACP y UCP como cuatro protocolos diferentes con una adopción relevante en el sector, lo que significa que MCP ya no es una curiosidad experimental. Forma parte de cómo se construyen realmente los sistemas de agentes en producción.
El protocolo de contexto de modelo permite que cualquier aplicación de IA compatible acceda a cualquier herramienta o fuente de datos compatible sin una integración personalizada para cada par. Esa es toda la propuesta de valor. Todo lo demás se deriva de ella.
El modelo cliente-servidor detrás de la arquitectura MCP
La especificación oficial de MCP describe una arquitectura de host-cliente-servidor en la que cada host puede ejecutar varias instancias de cliente. Cuatro componentes. Cada uno diferente.
Esto es lo que suele confundir a la gente: los términos «cliente» y «servidor» tienen un significado específico en MCP que no siempre coincide con el uso de esas palabras en las redes en general. Y «host» es una tercera cosa completamente distinta, no solo otra palabra para servidor. Vamos a desglosarlos para que realmente pueda dibujar el diagrama.
Host MCP: la aplicación que ejecuta el LLM
El host MCP es la aplicación que integra o ejecuta el modelo de lenguaje grande e inicia todo el proceso. Piense en Claude Desktop, Cursor o una aplicación de IA personalizada que haya creado su equipo. El host es aquello con lo que el usuario realmente interactúa.
El host también es responsable del control de acceso y la gobernanza de datos. Este es un detalle que se pasa por alto constantemente y es importante en producción. MCP no protege automáticamente las cosas. El host decide qué servidores pueden conectarse, a qué alcance de datos puede acceder cada cliente y quién tiene permiso para invocar qué herramientas. Si está implementando una aplicación de IA que interactúa con sistemas sensibles y no ha pensado bien esa capa, habrá lanzado una brecha de gobernanza.
Un host, varios clientes. Ese es el patrón.
Cliente MCP: el conector uno a uno dentro del host
Cada cliente MCP reside dentro del host y mantiene una conexión uno a uno con un único servidor MCP. Un cliente, un servidor. Esa es la limitación.
Sin embargo, un único host puede iniciar varios clientes simultáneamente, cada uno dirigido a un servidor diferente. Por tanto, si su host necesita comunicarse al mismo tiempo con un servidor de base de datos, un servidor de GitHub y un servidor interno de tickets, ejecuta tres clientes. Cada cliente gestiona su propio ciclo de vida de conexión, controla su propio estado de sesión y se comunica de forma independiente con su servidor correspondiente.
La distinción entre servidor y cliente importa aquí: el cliente no es el elemento de cara al usuario. Es la capa de conexión dentro del host. Tratarlos como si fueran intercambiables es donde los diagramas empiezan a equivocarse.
La lista de comprobación práctica antes de configurar esto:
- Confirme que la aplicación host admite varias conexiones de cliente simultáneas - Cada par cliente-servidor necesita su propia configuración de autenticación - El ciclo de vida del cliente (inicio, apagado, gestión de errores) lo administra el host - Si un servidor deja de funcionar, solo se ve afectado el cliente conectado a él, no todo el host
Servidor MCP: exposición de herramientas, recursos y prompts
El servidor MCP es el proceso independiente que expone capacidades al cliente. Es lo que su equipo crea (o adopta de una biblioteca existente de implementaciones de servidores MCP) cuando quiere dar a un LLM acceso a una fuente de datos o herramienta interna.
Un servidor expone tres tipos de capacidades, conocidas como primitivas: herramientas, recursos y prompts. Cubriremos las tres en la siguiente sección.
El servidor se ejecuta de forma independiente del host. No necesita saber nada sobre qué host o cliente se conecta a él. Esa independencia es lo que hace que el ecosistema sea componible: puede crear un servidor para su instancia interna de Confluence y cualquier host MCP compatible podrá conectarse a él. No necesita un conector personalizado por cada aplicación de IA. El servidor simplemente expone sus capacidades; el cliente las descubre.
Desde el punto de vista de las decisiones de desarrollo, aquí es donde sucede el trabajo real. Cuando los equipos preguntan «¿cómo conectamos nuestro asistente de IA con nuestras herramientas internas?», la respuesta es: cree o adopte un servidor MCP para cada herramienta. Las fuentes de datos a las que su LLM necesita acceder se empaquetan como recursos y herramientas del lado del servidor.
Primitivas de MCP: herramientas, recursos y prompts explicados
La especificación de MCP define tres tipos de capacidades que los servidores exponen a los clientes. Se denominan primitivas y son lo que hace útil a MCP más allá de ser una definición de protocolo genérica. Cada una tiene un propósito diferente.
Comprender las tres es lo que le permite pasar de «MCP conecta la IA con herramientas» a «esto es lo que nuestro servidor realmente expone y por qué».
Herramientas y llamadas a funciones en MCP
Las herramientas MCP son funciones ejecutables que el LLM puede invocar mediante el cliente. Si ha trabajado con llamadas a funciones en la API de OpenAI, el patrón le resultará familiar: describe una función, el modelo de lenguaje grande decide cuándo llamarla y se invoca con argumentos específicos.
Lo que MCP estandariza es cómo los modelos de IA descubren esas funciones en distintos servidores. Sin MCP, cada servidor tiene su propia estructura de descubrimiento. Con MCP, el cliente solicita al servidor una lista de sus herramientas disponibles utilizando el mismo formato de solicitud independientemente del servidor. El LLM ve un esquema de herramientas coherente sin importar cuántos servidores intervengan.
Un ejemplo práctico: un servidor para GitHub expone herramientas como search_repository, get_file_contents y create_pull_request. El LLM puede descubrirlas todas, comprender sus parámetros y ejecutarlas mediante el cliente sin ninguna integración personalizada en el lado del host. El servidor respalda estas herramientas con llamadas a la API de GitHub. MCP se sitúa sobre esas API; no las reemplaza.
El protocolo MCP también gestiona lo que sucede cuando falla una llamada a una herramienta, se limita por tasa de solicitudes o devuelve una respuesta inesperada. Ese ciclo de vida se encuentra en la capa de protocolo, lo que significa que el LLM no tiene que gestionarlo directamente.
Acceso a datos mediante recursos MCP
Los recursos son el mecanismo que los servidores MCP utilizan para exponer datos estructurados o no estructurados al cliente. Mientras que las herramientas realizan acciones, los recursos proporcionan contexto. Una herramienta podría ejecutar una consulta a una base de datos; un recurso expone el esquema para que el LLM pueda aportar contexto relevante antes de decidir qué consultar, o incluir datos directamente en su razonamiento.
Los recursos pueden ser documentos, registros de bases de datos, contenidos de archivos, resultados analíticos o cualquier elemento que proporcione información útil al LLM. El cliente los obtiene y el servidor devuelve los datos en un formato estandarizado.
Esto es importante para los equipos que conectan aplicaciones LLM a fuentes de datos existentes. En lugar de escribir lógica de recuperación personalizada para cada fuente de datos, encapsula la fuente en un servidor MCP y expone los datos relevantes como recursos. El LLM puede consultarlos sin saber nada sobre el sistema de almacenamiento subyacente.
Capa de transporte: cómo STDIO y HTTP+SSE mueven mensajes entre cliente y servidor
La capa de transporte es el canal de comunicación entre el cliente MCP y el servidor. La especificación de MCP utiliza JSON-RPC 2.0 como formato de mensaje en todos los transportes, lo que significa que la estructura de solicitudes y respuestas es coherente independientemente de la capa de transporte que elija.
En el protocolo central se definen dos transportes: STDIO y HTTP con Server-Sent Events.
STDIO es el transporte local. El host inicia el servidor MCP como un subproceso, y el cliente y el servidor se comunican mediante flujos de entrada y salida estándar. Esto es habitual en implementaciones locales de MCP, donde el servidor se ejecuta en la misma máquina que el host. La mayoría de las integraciones de IDE (Cursor, extensiones de VS Code) utilizan STDIO porque el servidor es un proceso local. La configuración es sencilla; no hay una superficie de red de la que preocuparse.
HTTP+SSE es el transporte remoto. El servidor se ejecuta como un proceso independiente, potencialmente en otra máquina o en otro entorno, y la comunicación entre el cliente MCP y el servidor ocurre mediante HTTP. Server-Sent Events gestiona la dirección de mensajes del servidor al cliente, mientras que el cliente envía mensajes mediante HTTP POST convencional. Esto es lo que utiliza cuando el servidor se aloja de forma remota, se comparte entre varios hosts o se implementa como un servicio.
Las versiones de protocolo para cada uno se definen en la especificación, y los dos transportes no son intercambiables en tiempo de ejecución. Elige uno en el momento de la implementación, y esa elección tiene consecuencias.
| Situación | Transporte | Motivo |
|---|---|---|
| Subproceso local (plugin de IDE, aplicación de escritorio) | STDIO | Misma máquina, baja sobrecarga, sin exposición de red |
| Servidor remoto compartido (acceso para todo el equipo) | HTTP+SSE | Entre máquinas, accesible desde varios hosts |
| Servidor implementado en la nube | HTTP+SSE | Accesible por red por diseño |
| Desarrollo/pruebas en máquina local | STDIO | Configuración más sencilla, no requiere configuración de autenticación |
🤔 Espere.
La selección del transporte parece una preferencia de conectividad. En realidad, es una decisión de límite arquitectónico. STDIO significa que su servidor se ejecuta en la máquina host MCP, lo que define su modelo de implementación, su perímetro de seguridad y si el servidor puede compartirse con otros hosts. HTTP+SSE significa que su servidor es accesible por red, lo que abre cuestiones de gobernanza completamente diferentes. La elección «simple» conlleva compromisos arquitectónicos.
Cómo se compara la arquitectura MCP con una integración directa de API
El malentendido más persistente que veo es que MCP reemplaza las API. No es así. Permítame ser directo sobre lo que realmente hace.
MCP es una capa de protocolo estándar que se sitúa por encima de las API. Cuando un servidor MCP expone una herramienta como search_database, esa herramienta está respaldada por una llamada a una API (o una consulta a una base de datos, o una lectura de archivo). MCP estandariza cómo el LLM descubre la herramienta y la invoca. La API subyacente sigue existiendo. MCP simplemente proporciona una interfaz coherente para llamarla.
La analogía que mejor funciona es el Language Server Protocol, utilizado por todos los principales editores de código. LSP estandarizó cómo los editores se comunican con las herramientas de análisis de lenguajes. Antes de LSP, cada editor escribía integraciones personalizadas con cada servidor de lenguaje. Después de LSP, cualquier editor compatible se conecta a cualquier servidor de lenguaje compatible. MCP sigue el mismo patrón para las aplicaciones de IA y las herramientas externas.
El problema de conectar sistemas de IA que resuelve MCP se denomina a veces el problema de integración N×M. Sin un protocolo estándar, conectar N aplicaciones de IA a M herramientas requiere hasta N×M conectores personalizados. Con un estándar MCP, cada aplicación de IA implementa MCP una vez (el lado del cliente), cada herramienta implementa MCP una vez (el lado del servidor), y cualquier par compatible puede conectarse.
📊 En la práctica:
Sin MCP, conectar asistentes de IA a cinco herramientas internas significa cinco capas de integración personalizadas, cada una con su propia autenticación, gestión de errores y mecanismo de descubrimiento, mantenidas por separado a medida que cambia cualquiera de las cinco herramientas. Con MCP, un único cliente compatible en el host se conecta a los cinco servidores mediante el mismo protocolo. Cuando un servidor actualiza su esquema de herramientas, el cliente descubre el cambio a través del flujo estándar de negociación de capacidades, no mediante una actualización de adaptador a medida.
Los sistemas externos que necesita su LLM —bases de datos, API, almacenes de archivos y servicios internos— no desaparecen detrás de MCP. Siguen ahí. MCP simplemente evita que tenga que escribir un conector único para cada aplicación de IA que necesite acceder a ellos.
Dónde encaja la arquitectura MCP en los flujos de IA agéntica
Aquí hay otro malentendido que merece abordarse directamente: MCP no es un marco de agentes.
Un sistema agéntico necesita, como mínimo, una capa de planificación (algo que decide qué hacer a continuación), una capa de gestión de memoria o contexto (algo que registra lo que ha ocurrido) y una capa de acceso a herramientas (algo que se conecta con sistemas externos para realizar acciones). MCP se encarga de la tercera. No se encarga de las dos primeras.
Al crear agentes de IA, el marco de agentes situado sobre MCP es responsable de la lógica: qué objetivo perseguir, qué pasos seguir, cuándo reintentar, cuándo abandonar y cómo gestionar el contexto a lo largo de varios turnos. MCP gestiona cómo se accede a esas herramientas y fuentes de datos una vez que el marco ha decidido acceder a ellas.
La relación es la siguiente: los sistemas agénticos usan MCP para acceder a herramientas, no MCP para ejecutar agentes.
Esta distinción importa para los sistemas agénticos en la fase de diseño. Cuando su flujo empieza a comportarse mal, necesita saber si el problema está en la lógica del agente (decisión incorrecta, objetivo incorrecto, gestión de contexto incorrecta) o en la capa de acceso a herramientas (servidor incorrecto, llamada fallida, parámetro incorrecto). Si ha confundido ambas cosas, el diagnóstico es mucho más difícil.
En la práctica, el flujo se sitúa por encima de MCP en la pila. El marco de agentes decide cuándo llamar a una herramienta; MCP gestiona cómo se realiza esa llamada y cómo regresa la respuesta. El comportamiento de IA consciente del contexto depende del marco de agentes para gestionar el contexto; MCP solo proporciona el mecanismo para obtener contexto adicional cuando el marco lo solicita.
Un ejemplo concreto: un equipo de herramientas para desarrolladores de una organización de ingeniería mediana quería que su asistente de programación de IA pudiera buscar en repositorios de código internos, iniciar ejecuciones de CI/CD y crear tickets de incidentes sin salir del IDE. Crearon tres servidores MCP (uno por herramienta), cada uno exponiendo herramientas y recursos relevantes, y los conectaron al host del IDE mediante la capa de cliente. Los sistemas de IA del IDE ahora llaman a esas herramientas. Pero la lógica que determina cuándo iniciar una ejecución de CI y cuándo simplemente mostrar una advertencia reside en el marco de agentes que está por encima de todo. La comunicación entre los componentes de IA y los servidores es responsabilidad de MCP. El razonamiento sobre qué hacer no lo es.
Si utiliza AI Agent Builder y MCP Server Builder de Latenode conjuntamente, esta división se hace visible en el lienzo: el servidor MCP expone qué herramientas están disponibles y el flujo del agente decide cuándo invocarlas. Esa separación no es solo una arquitectura limpia en un diagrama: es lo que hace posible la depuración cuando el agente realiza una llamada incorrecta.
Responsabilidades de seguridad y gobernanza en una implementación de MCP
MCP define la interfaz de integración. No implementa su política de seguridad. Los equipos que lanzan sistemas conectados mediante MCP esperando que el protocolo gestione el control de acceso descubren esto en producción, normalmente en un momento inoportuno.
Estas son las responsabilidades que pertenecen a su implementación, no a MCP en sí:
- Aplicación del control de acceso (host)
El host decide a qué servidores MCP puede conectarse cada cliente y qué alcance se permite para cada conexión. MCP no proporciona ningún mecanismo integrado para impedir que un cliente se conecte a un servidor al que no debería acceder. La aplicación de IA debe implementar esta comprobación explícitamente antes de iniciar un cliente.
- Alcance de datos por herramienta y recurso (servidor)
El servidor es responsable de devolver solo los datos que el solicitante está autorizado a ver. Si su servidor MCP encapsula una base de datos y un cliente envía una consulta de recursos, el servidor debe aplicar el acceso a nivel de fila o esquema antes de devolver resultados. El modelo de lenguaje y la capa de cliente no tienen visibilidad sobre si los datos devueltos tenían el alcance adecuado.
- Gestión del ciclo de vida de autenticación (host y servidor)
Los tokens OAuth, las claves API y las credenciales de servicio caducan. El host debe gestionar la renovación de tokens para los clientes, y el servidor debe validar la autenticación en cada solicitud, no solo al momento de la conexión. Un patrón de fallo habitual: la autenticación se valida al inicio, se degrada silenciosamente y empieza a devolver errores 401 horas más tarde. El panel suele parecer correcto hasta que alguien advierte que los datos han dejado de moverse.
- Registro de auditoría (host y servidor)
MCP no incluye un registro de auditoría integrado. Si necesita un historial de qué herramientas se llamaron, con qué argumentos, por qué cliente y qué se devolvió, debe crear ese registro usted mismo, tanto del lado del servidor (para las invocaciones de herramientas) como del lado del host (para los eventos de sesión).
- Aislamiento de servidores (servidor)
Cada servidor MCP debería operar de forma independiente con su propio conjunto de credenciales y alcance de acceso. Un servidor con permisos amplios que se vea comprometido expone todo lo que haya dentro de ese alcance. Si una consulta falla en un servidor, no debería propagarse a los demás. El aislamiento es una decisión arquitectónica, no una garantía del protocolo.
