Arquitectura MCP (Model Context Protocol): Componentes, Tecnologías y Flujos

La arquitectura MCP (Model Context Protocol) es un estándar abierto de tipo cliente-servidor basado en JSON-RPC 2.0 que conecta aplicaciones de inteligencia artificial con fuentes de datos y herramientas externas de forma segura y estandarizada. Su propósito es resolver el problema histórico de la integración N×M: sin un protocolo común, cada aplicación de IA necesitaba un conector distinto para cada fuente de datos o API, generando un crecimiento combinatorio de código de integración. MCP reduce este problema a una integración N+M: cualquier host compatible puede hablar con cualquier servidor compatible sin adaptadores personalizados.

Componentes principales

• Host MCP: la aplicación principal impulsada por IA (como Claude Desktop o un entorno de desarrollo) que necesita acceder a datos externos.
• Cliente MCP: mantiene una conexión directa y bidireccional con el servidor y opera dentro del host para mediar la comunicación.
• Servidor MCP: expone de forma controlada las capacidades externas, divididas en tres tipos: Recursos (datos), Herramientas (acciones ejecutables) y Sugerencias (prompts).

Beneficios de la arquitectura

• Modularidad: permite cambiar o reutilizar fuentes de datos sin alterar el modelo de IA base.
• Estandarización: elimina la necesidad de crear adaptadores personalizados para cada API o base de datos distinta.
• Seguridad: controla de manera estricta qué información y funciones se comparten con los agentes inteligentes, típicamente exigiendo aprobación humana antes de ejecutar una herramienta.

Host MCP: Tecnologías Core para la Operación

El Host es la aplicación que orquesta la experiencia del usuario y consume los servicios del protocolo. No implementa el protocolo MCP directamente; delega esa función al Cliente MCP que aloja internamente. Sus tecnologías core se centran en tres frentes: ejecución del modelo de lenguaje, gestión del contexto/orquestación de agentes, y aislamiento seguro de procesos.

1. Motores de Inferencia (LLM Cores)

Sistemas locales o basados en API que procesan el lenguaje natural y generan las decisiones de invocación de herramientas. Incluyen las APIs de Anthropic Claude u OpenAI API, o motores locales como Ollama y Llama.cpp para ejecutar modelos abiertos (Llama 3, Mistral) directamente en hardware local, sin dependencia de servicios en la nube.

2. Orquestadores de Agentes y Prompts

Librerías de software que gestionan el ciclo de vida del contexto, el historial de conversación y las llamadas a herramientas (tool calling). Destacan LangChain, LlamaIndex y el SDK nativo de Anthropic (anthropic-sdk-python / anthropic-sdk-typescript). Estas librerías son las responsables de mantener la ventana de contexto, decidir cuándo insertar los resultados de una herramienta en la conversación, y encadenar múltiples llamadas cuando una tarea requiere varios pasos.

3. Aislamiento de Procesos (Sandboxing)

Tecnologías para ejecutar código o comandos del servidor de forma segura sin comprometer el sistema operativo anfitrión. Se aplican contenedores Docker, entornos virtuales de Python (venv) o microVMs como Firecracker cuando se requiere aislamiento a nivel de kernel para cargas multi-tenant. En el caso de servidores locales lanzados por stdio (como los que configuramos en claude_desktop_config.json), el aislamiento mínimo recomendado es, como mínimo, un entorno virtual dedicado por proyecto.

Cliente MCP: Programas y Herramientas para Operar

El Cliente actúa como el puente de traducción (el "enchufe") dentro del Host para hablar el protocolo MCP mediante canales Standard Input/Output (stdio) o WebSockets/SSE. No es una aplicación separada que el usuario instala por su cuenta, sino un módulo embebido dentro del Host. Los programas que ya integran o pueden operar como clientes MCP son:

IDEs y Entornos de Desarrollo

Editores de código que conectan la IA directamente con el espacio de trabajo del desarrollador. VS Code (mediante extensiones de agentes), Cursor y Zed Editor cuentan con soporte nativo o integrado para conectarse a servidores MCP locales, permitiendo que el asistente de código lea el repositorio, ejecute comandos o consulte documentación a través de un servidor MCP configurado en el propio editor.

Aplicaciones de Escritorio de IA

Interfaces de chat avanzadas. Claude Desktop es el cliente de referencia oficial que permite configurar servidores MCP modificando su archivo claude_desktop_config.json, tal como se documentó en los artículos anteriores de esta serie.

Herramientas de CLI y Automatización

Frameworks de terminal para desarrolladores como Smithery AI (para gestionar e instalar servidores MCP fácilmente desde un registro centralizado) y herramientas de automatización de flujos de trabajo como n8n, que permiten incorporar nodos MCP dentro de pipelines de automatización más amplios, combinando servidores MCP con lógica condicional, triggers y otras integraciones no-MCP.

Servidor MCP: Capacidades y Tecnologías de Desarrollo

El Servidor expone los datos y las funciones. Se construye utilizando SDKs oficiales y se puede personalizar en tres capacidades core, todas transportadas sobre el estándar JSON-RPC 2.0:

1. Tecnologías para Construir el Servidor

• Runtimes de ejecución: principalmente Node.js / TypeScript (usando el paquete @modelcontextprotocol/sdk) o Python (usando el paquete oficial mcp, o frameworks de alto nivel como fastmcp, utilizado en los servidores construidos previamente en esta serie).
• Protocolos de transporte:
  • stdio — lectura/escritura estándar en consola, usada por servidores locales lanzados como subproceso del Host (el modelo que hemos usado en MiServidorPython y en el servidor filesystem personalizado).
  • SSE (Server-Sent Events) / WebSockets — usados por servidores remotos o desplegados en la nube, accesibles vía red en lugar de como proceso hijo.

2. Personalización de las 3 Capacidades Core

A. Recursos (Resources)

Son datos legibles que el servidor pone a disposición del modelo — equivalente a "leer un archivo" o "consultar una base de datos". Son de naturaleza pasiva: no modifican estado, solo lo exponen.

• Qué tecnologías usar: conectores de bases de datos (Prisma ORM, pg para PostgreSQL, sqlite3), lectores de archivos de sistema (fs en Node, os/pathlib en Python, como en el servidor filesystem desarrollado previamente) o clientes API para obtener texto de fuentes externas.
• Cómo generarlo/personalizarlo: se definen mediante URIs personalizadas (por ejemplo file://logs/app.log o postgres://usuarios/recientes). En el código del servidor se registra un manejador de listado de recursos (listResources) y un manejador de lectura (readResource). Cuando el cliente solicita la URI, la función personalizada ejecuta la consulta SQL o lee el archivo correspondiente y devuelve el contenido en texto plano o binario. En FastMCP, esto se implementa de forma declarativa con el decorador @server.resource("uri://patron"), de manera análoga a como @server.tool() registra una herramienta.

B. Herramientas (Tools)

Son acciones ejecutables que el modelo puede decidir invocar — equivalente a "hacer algo" en el mundo real. A diferencia de los recursos, las herramientas tienen efectos secundarios (escribir, enviar, mutar estado) y por eso requieren aprobación explícita del usuario en clientes como Claude Desktop.

• Qué tecnologías usar: librerías de automatización como Puppeteer (para web scraping y control de navegador), clientes HTTP como Axios o requests en Python (para disparar webhooks o interactuar con APIs como GitHub, Slack, Jira), y ejecutores de comandos de sistema (child_process en Node, subprocess en Python).
• Cómo generarlo/personalizarlo: se diseña un esquema JSON que describe el nombre de la herramienta, una descripción detallada (clave para que el LLM sepa cuándo usarla — el docstring en FastMCP cumple exactamente este rol, como se vio en el servidor crear_archivo_markdown) y los parámetros requeridos, normalmente inferidos automáticamente a partir de type hints. La herramienta se registra en el manejador listTools. Cuando el LLM decide usarla, envía un evento callTool con los argumentos estructurados; el servidor recibe esos parámetros, ejecuta la acción física (enviar un correo, mutar una API, crear un archivo) y retorna el resultado al modelo.

C. Sugerencias (Prompts)

Son plantillas preconfiguradas de texto que ayudan al usuario y al host a estructurar las interacciones con la IA, típicamente seleccionables desde la interfaz del cliente como atajos de flujo de trabajo.

• Qué tecnologías usar: motores de plantillas de texto simples (variables por string templates en JavaScript o f-strings en Python) o repositorios de prompts versionados cuando el catálogo crece en tamaño y necesita control de cambios.
• Cómo generarlo/personalizarlo: se crean combinaciones de texto con argumentos dinámicos — por ejemplo, un prompt llamado analizar-codigo que acepte un parámetro lenguaje. Se registra en el manejador listPrompts. Cuando el usuario lo selecciona en la interfaz del cliente, el servidor devuelve la estructura del prompt combinada con los datos contextuales actuales, facilitando tareas complejas o flujos de trabajo repetitivos sin que el usuario tenga que redactar el mismo prompt largo cada vez.

Flujo completo end-to-end

El siguiente diagrama resume cómo interactúan los tres componentes desde que el usuario escribe una petición hasta que recibe la respuesta, incluyendo el punto de control humano característico de MCP:

Recursos adicionales para profundizar

• Especificación oficial del protocolo: modelcontextprotocol.io
• Documentación y guía de depuración: modelcontextprotocol.io/docs/tools/debugging
• SDK oficial de Python: github.com/modelcontextprotocol/python-sdk
• SDK oficial de TypeScript: github.com/modelcontextprotocol/typescript-sdk
• Framework FastMCP: gofastmcp.com
• Registro/directorio de servidores MCP de la comunidad: smithery.ai
• Documentación de configuración de Claude Desktop: support.claude.com

Resumen

• MCP estandariza la comunicación entre aplicaciones de IA (Host) y fuentes externas de datos/acciones (Servidor) mediante un Cliente MCP embebido que traduce esa interacción a JSON-RPC 2.0.
• El Host depende de tres tecnologías core: un motor de inferencia LLM, un orquestador de agentes/contexto, y un mecanismo de aislamiento de procesos para ejecutar servidores de forma segura.
• El Cliente no es una aplicación separada, sino un módulo embebido en IDEs (VS Code, Cursor, Zed), aplicaciones de escritorio (Claude Desktop) o herramientas de automatización (n8n, Smithery AI).
• El Servidor se construye típicamente en Node.js/TypeScript o Python, y expone tres capacidades diferenciadas — Recursos (lectura pasiva), Herramientas (acciones con efectos secundarios y aprobación humana) y Sugerencias (plantillas reutilizables) — cada una con su propio manejador de listado y ejecución dentro del protocolo.
• El punto de control de seguridad más importante del flujo end-to-end es la aprobación explícita del usuario antes de que cualquier herramienta con efectos secundarios se ejecute, lo cual distingue a MCP de una integración de function-calling sin supervisión.