Conoce los tres pilares de la arquitectura MCP y entiende cómo Host, Client y Server trabajan juntos para conectar la IA con el mundo real.
O Host es la aplicación donde se ejecuta realmente el modelo de IA. Es el punto de partida de todo: la interfaz que ve el usuario, el entorno que contiene el modelo y el lugar donde se inicia la comunicación con el mundo externo. Sin el Host, el modelo no tiene dónde existir: es la «casa» de la IA.
El Host es la aplicación anfitriona que aloja el modelo de IA y gestiona todo el ciclo de vida de la interacción. Es responsable de iniciar la comunicación, mostrar los resultados al usuario y coordinar los Clients que se conectan a los Servers. Algunos ejemplos concretos de Hosts son:
Aplicación oficial de Anthropic que ejecuta Claude localmente con compatibilidad nativa con MCP.
IDE que integra modelos de IA para ayudar en la programación y que puede funcionar como Host MCP.
Aplicación interna personalizada que incorpora un modelo de IA para automatizar procesos.
El concepto de Host en MCP se inspiró en la arquitectura de Language Server Protocol (LSP), creado por Microsoft para editores de código. Al igual que con LSP, donde el editor (VS Code, Neovim, etc.) es el host que se comunica con servidores de lenguaje, en MCP el Host es la aplicación que contiene el modelo y orquesta la comunicación. Esta decisión arquitectónica permite que cualquier aplicación se convierta en un Host MCP, desde asistentes personales hasta plataformas empresariales de gran escala.
O Client es el mensajero de la arquitectura MCP. Vive dentro del Host y se encarga de traducir las necesidades del modelo en solicitudes estandarizadas que los Servers pueden entender. Cada Client mantiene una conexión dedicada con un Server específico, y un único Host puede contener múltiples Clients — cada uno conectado a un Server diferente.
El Client administra el ciclo de vida de la conexión entre el Host y un Server. Sus responsabilidades incluyen: iniciar y cerrar conexiones, enviar solicitudes en formato MCP, recibir y procesar respuestas, manejar errores y timeouts, y mantener el estado de la sesión. El Client abstrae toda la complejidad de la comunicación: el modelo no necesita saber cómo comunicarse con cada herramienta, solo pide lo que necesita y el Client lo traduce. Un Host como Claude Desktop puede tener al mismo tiempo un Client conectado a GitHub, otro a PostgreSQL y otro al sistema de archivos local.
El Client es como un traductor simultáneo entre el modelo y las herramientas. Imagina que el modelo habla "portugués" y cada herramienta habla un idioma diferente: la base de datos habla "SQL", GitHub habla "API REST" y el sistema de archivos habla "comandos del SO". El Client lo traduce todo al formato estandarizado MCP, para que la comunicación fluya perfectamente sin que ninguna de las partes tenga que aprender el idioma de la otra.
O Server es el componente que expone capacidades al modelo de IA. Pone a disposición Tools (herramientas que ejecutan acciones), Resources (datos que se pueden leer) y Prompts (plantillas de interacción reutilizables). Cada Server está especializado en un dominio específico: hay un Server para GitHub, otro para bases de datos, otro para correo electrónico, y así sucesivamente.
El Server MCP es un programa que expone capacidades estandarizadas para que los Clients las consuman. Sirve de puente entre el protocolo MCP y los sistemas externos reales. Por ejemplo, un Server de GitHub recibe una solicitud MCP del tipo "lista los pull requests abiertos" y la traduce en llamadas a la API de GitHub; luego devuelve el resultado en el formato estandarizado. La filosofía es que cada Server sea enfocado y especializado — un Server por cada dominio, cada uno haciendo bien una sola cosa.
Ahora que conoces los tres pilares —Host, Client y Server—, es hora de ver cómo trabajan juntos en un flujo real de principio a fin. Desde el momento en que el usuario hace una pregunta hasta la respuesta final, cada componente cumple un papel preciso en esta orquestación.
El flujo MCP sigue una cadena bien definida: el usuario hace una solicitud al Host, el modelo dentro del Host identifica que necesita datos o acciones externas, el Client traduce esa necesidad en una solicitud MCP estandarizada, el Server ejecuta la acción en el sistema externo y el resultado vuelve al modelo, que formula la respuesta final para el usuario. Todo esto sucede de forma transparente: el usuario no necesita saber que se consultaron varios sistemas en segundo plano.
El usuario envía un mensaje al Host. Ejemplo: "¿Cuáles son los pull requests abiertos en mi repositorio?"
El modelo de IA dentro del Host analiza la pregunta y determina que necesita acceder a GitHub para responderla. Identifica qué tool del Server MCP debe llamarse.
El Client del Host convierte la necesidad del modelo en una solicitud MCP estandarizada y la envía al Server de GitHub.
El Server de GitHub recibe la solicitud, llama a la API de GitHub, obtiene la lista de pull requests abiertos y da formato al resultado.
El Server envía la respuesta estandarizada al Client, que se la pasa al modelo dentro del Host.
El modelo procesa los datos recibidos y formula una respuesta natural para el usuario: "Tienes 3 PRs abiertos: #42 (fix login), #38 (add tests), #35 (update docs)."
Para consolidar la arquitectura en tu mente, vamos a construir un mapa mental de la estructura MCP. Visualizar cómo encajan las piezas es fundamental para entender dónde empieza y termina cada componente, y cómo fluye la información entre ellos.
La arquitectura MCP sigue una jerarquía clara de contención y conexión:
El Host contiene el modelo y los Clients. Cada Client se conecta a exactamente un Server. Cada Server se conecta a uno o más sistemas externos. Esta separación garantiza modularidad, seguridad y escalabilidad.
Piensa en la arquitectura MCP como un oficina moderna. El Host es el edificio de la oficina donde ocurre todo. El modelo de IA es el director que toma decisiones. Los Clients son los asistentes ejecutivos: cada uno está especializado en tratar con un proveedor diferente. Y los Servers son los proveedores externos (banco, correo, TI) que ejecutan los servicios solicitados. El director no llama directamente a cada proveedor: le pide ayuda al asistente adecuado, que sabe exactamente cómo comunicarse con ese proveedor.
La teoría cobra vida con ejemplos concretos. Analicemos dos escenarios reales de uso de la arquitectura MCP —uno para desarrolladores y otro para equipos de negocio— para ver cómo se articulan Host, Client y Server en la práctica.
La belleza de la arquitectura MCP es que funciona de la de la misma forma independiente del escenario. Ya seas un programador que solicita un análisis de código o un equipo de ventas que consulta métricas, el flujo Host → Client → Server permanece idéntico. Lo que cambia son los Servers conectados y las Tools disponibles, pero la arquitectura, el protocolo y el estándar de comunicación son siempre los mismos. Esta consistencia es lo que hace que MCP sea tan poderoso.
Un desarrollador abre Claude Desktop y pide: «Analiza los últimos commits de mi repo y sugiere mejoras».
Host: Claude Desktop (aplicación con el modelo Claude)
Client: Client MCP interno de Claude Desktop
Server: Server MCP de GitHub (accede a la API de GitHub)
Flujo: Claude identifica la necesidad → Client envía una solicitud al Server GitHub → Server consulta los commits mediante la API → vuelve el resultado → Claude presenta un análisis con sugerencias
Un gerente de ventas usa la plataforma interna de la empresa y pregunta: «¿Cuáles fueron los ingresos del último trimestre por región?»
Host: Aplicación interna de la empresa (con un modelo de IA integrado)
Client: Client MCP configurado en la aplicación
Server: Server MCP de PostgreSQL (se conecta a la base de datos)
Flujo: El modelo identifica la necesidad de datos → el Client envía una solicitud al Server PostgreSQL → el Server ejecuta una query SQL → se devuelve el resultado → el modelo presenta un informe con formato y datos por región
¡Ten cuidado con los permisos! El hecho de que un Server MCP pueda ejecutar acciones en sistemas externos hace que el control de acceso sea fundamental. Cada Server debe tener solo los permisos mínimos necesarios: el Server de GitHub no necesita acceso a la base de datos, y el Server de PostgreSQL no necesita acceso a GitHub. Aplica siempre el principio de privilegio mínimo: concede solo los permisos estrictamente necesarios para que cada Server cumpla su función.
Siguiente Módulo: 1.4 — Viendo el MCP en acción