Guía para principiantes: cómo entender visualmente la arquitectura de MCP

El Model Context Protocol (MCP) ha abierto muchísimas posibilidades para ampliar las capacidades de los modelos de lenguaje grandes, pero también ha generado cierta confusión. Por eso me propuse crear una guía para principiantes que explique visualmente cómo es una arquitectura MCP, con diagramas y todo.

Si eres desarrollador, probablemente hayas escuchado que los servidores MCP están impulsando el desarrollo de software con agentes en herramientas como Cursor, Windsurf e incluso los nuevos flujos de trabajo con agentes de VS Code. Sin embargo, sus aplicaciones van más allá del software y permiten ofrecer experiencias fluidas y enriquecedoras con LLM para usuarios finales, ya que amplían el modelo más allá de los datos con los que se entrenó y aprovechan su capacidad de razonamiento para ejecutar acciones.

Entender MCP

En esencia, los LLM son una base de conocimientos comprimida con todos los datos con los que se entrenaron. Si tomamos como referencia el funcionamiento del cerebro, aprenden mediante un concepto similar al de las redes neuronales, que les permite razonar y dar saltos lógicos importantes que se asemejan a la inteligencia. Por impresionantes que sean los modelos de lenguaje grandes, siguen limitados a sus propios datos.

MCP es el puente que conecta los LLM con conocimientos y acciones que están fuera de su alcance. Algunos dirían que esto ya existía cuando OpenAI presentó las capacidades de llamada a funciones o llamada a herramientas hace un tiempo. Sin embargo, MCP tomó ese concepto y lo amplió para convertirlo en un estándar de comunicación abierto, con interfaces estructuradas bien definidas, y habilitó la implementación y el descubrimiento de herramientas de forma distribuida y dinámica. Más adelante hablaremos sobre MCP y la llamada a funciones.

Hosts, clientes y servidores MCP

Ahora que hemos explicado el propósito de MCP, podemos desglosar sus componentes básicos. MCP incluye tres entidades:

• El host MCP es la aplicación impulsada por IA que se integra con MCP. Algunos ejemplos prácticos son Claude Desktop, Cursor, Windsurf, VS Code y otras. Estas aplicaciones se integran con MCP mediante la implementación de un cliente MCP.

• El cliente MCP: es la capa de implementación básica, que suele estar alojada en aplicaciones de IA con funciones avanzadas, marcos de trabajo con agentes y otras aplicaciones similares. Es la interfaz que se comunica con los servidores MCP.

• El servidor MCP: es el componente que proporciona capacidades del “mundo real”. El LLM no tiene acceso a tus archivos locales, ¿verdad? Pero si un servidor MCP los pone a disposición, el LLM puede listarlos, leerlos y modificarlos. Los servidores MCP implementan estas capacidades ampliadas, conocimientos y acciones a los que ahora puede acceder el LLM.

Nota: es probable que veas que a los hosts MCP a menudo simplemente se les llama clientes MCP, porque ese término se ha extendido una capa hacia arriba y ahora significa que el cliente MCP es, en la práctica, la aplicación impulsada por IA.

Breve introducción a la llamada a funciones y las herramientas

Por lo general, los servidores MCP ponen herramientas a disposición de los clientes MCP. Algunos ejemplos son “leer un archivo” o “listar todas las ramas de un repositorio git remoto”.

¿Cómo lo hacen? Le dicen al LLM: “Oye, estas son las herramientas que tengo disponibles para ti; una se llama read_file”. Entonces, el LLM puede activar específicamente esta herramienta mediante el Model Context Protocol, que a su vez la vincula con una implementación de función real en el código del servidor MCP:

function tool_read_file(filepath) {
   // implementation
}

Pero las herramientas no son algo nuevo. La llamada a herramientas, también conocida como llamada a funciones, fue presentada por OpenAI a finales de 2023. Luego, cada aplicación impulsada por IA implementó la llamada a funciones y debía coordinarla específicamente para el LLM. Y, lo que es más importante, no todos los modelos admitían la llamada a funciones.

Más adelante veremos cómo MCP ofrece una solución integral mejor que la llamada a funciones.

Tipos de transporte de los servidores MCP: STDIO vs. HTTP

Al principio, los servidores MCP pueden dar la impresión de ser servidores basados en redes, pero su popularidad se debe a procesos que se ejecutan localmente y se comunican mediante el transporte de entrada y salida estándar.

¿Qué es STDIO?

STDIO (entrada, salida y error estándar) es un mecanismo de comunicación basado en texto fundamental para los procesos del sistema. Es decir, para comandos o programas como ejecutar git en la línea de comandos.

Cuando se ejecuta un programa, el sistema operativo establece tres canales predeterminados: stdin para recibir entradas (normalmente del teclado o de la salida de otro programa), stdout para la salida normal (por lo general, la terminal o un archivo) y stderr para mensajes de error y diagnóstico (también suele ser la terminal, aunque con frecuencia se separa).

En resumen, STDIO permite que los programas interactúen con el sistema operativo u otros programas. Por ejemplo, puedes canalizar la salida de un comando (su stdout) como entrada (stdin) para otro comando. De manera similar, puedes redirigir stdout o stderr de un programa a un archivo para registrar los datos o revisarlos más adelante. Muchas herramientas de línea de comandos dependen en gran medida de STDIO para las canalizaciones de procesamiento de datos y la interacción básica.

En sistemas con arquitecturas cliente-servidor, como los servidores MCP, STDIO puede ofrecer un método sencillo: el servidor MCP es un proceso que recibe solicitudes (mediante stdin) y las devuelve al cliente MCP como respuestas de texto (mediante stdout).

Servidores MCP locales con STDIO

Los servidores MCP que se comunicaban mediante STDIO dependían de un proceso en ejecución y, por lo tanto, en su mayoría, eran servidores MCP que se ejecutaban e instalaban localmente.

Por eso, muchas aplicaciones impulsadas por IA (también llamadas hosts MCP) requerían que los usuarios proporcionaran definiciones de servidores MCP centradas en la ejecución de procesos. Aquí tienes un ejemplo sencillo tomado de la definición de servidores MCP mcp.json de Cursor:

// This example demonstrated an MCP server using the stdio format
// Cursor automatically runs this process for you
// This uses a Node.js server, ran with `npx`
{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

Cómo escalar los servidores MCP a la nube

Por fin, los servidores MCP pueden cumplir plenamente con las expectativas gracias a la adopción generalizada del transporte HTTP en aplicaciones de IA como Cursor y Claude Desktop, junto con la compatibilidad de infraestructuras en la nube como Vercel y Cloudflare para alojar servidores MCP.

Al principio, los servidores MCP incorporaron un transporte HTTP basado en redes, que dependía de un mecanismo llamado SSE (Server-Sent Events) para sincronizar y coordinar mensajes entre el LLM y el servidor MCP. Sin embargo, al igual que WebSockets, SSE requiere servidores de ejecución prolongada, que no son tan fáciles de usar en plataformas de implementación modernas como Vercel Functions o AWS Lambda. Así surgió una nueva especificación de HTTP transmitible que habilita HTTP sin servidor para los servidores MCP.

Los servidores MCP basados en HTTP son fáciles de configurar porque solo requieren la dirección de un host remoto, no una especificación compleja de argumentos de línea de comandos. También facilitan compartir y acceder a los servidores MCP, ya que ya no es necesario configurar y ejecutar un entorno de desarrollo específico de forma local.

Por ejemplo, Cursor espera que los servidores MCP remotos mediante HTTP se definan de forma sencilla así:  

// This example demonstrated an MCP server using the SSE format
// The user should manually setup and run the server
// This could be networked, to allow others to access it too
{
  "mcpServers": {
    "server-name": {
      "url": "http://example.com/sse",
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

La arquitectura MCP: todo en conjunto

Ahora que hemos explicado los componentes básicos de MCP, como los clientes y servidores MCP, los tipos de transporte que usan para comunicarse y ejemplos prácticos de cada uno, podemos entender mejor el modelo de implementación y la arquitectura general de MCP.

La arquitectura MCP permite implementar MCP de forma local y remota, lo que posibilita muchos tipos de configuración y estrategias de implementación. Por ejemplo, puedes ejecutar aplicaciones de IA compatibles con MCP por completo de forma local. Aquí tienes un ejemplo real: instalas una aplicación local de IA, como la aplicación de productividad Raycast o el IDE Cursor. Luego, proporcionas a Raycast o Cursor un LLM que se ejecute localmente mediante Ollama. Las aplicaciones Raycast o Cursor ejecutan un cliente MCP local, que configuras con un servidor MCP local, como un servidor MCP de SQLite, para explorar registros de bases de datos basadas en archivos.

El ejemplo anterior muestra una aplicación impulsada por IA que se ejecutaría completamente de forma local en una laptop, sin necesitar acceso a la nube ni a una red.

Como alternativa, puedes combinar distintas opciones. Puedes implementar el servidor MCP en una infraestructura en la nube y ponerlo a disposición mediante transporte HTTP. El cliente y el servidor MCP se comunican mediante el Model Context Protocol, según la especificación, lo que permite desacoplarlos por completo.

Además, aunque la gran mayoría de las aplicaciones impulsadas por IA han alojado la implementación del cliente MCP como parte de la propia aplicación de IA, esto no es estrictamente necesario: el cliente MCP también puede desacoplarse de la aplicación de IA.

MCP vs. llamada a funciones: por qué MCP no es simplemente una capa para API

Muchos califican a MCP como “otra capa más para API REST”. Es una percepción limitada y despectiva, así que veamos por qué MCP es más complejo y se adapta mejor a las aplicaciones de IA.

Antes de profundizar en la confusión entre MCP y las API REST, algunos desarrolladores quieren entender mejor cómo y por qué MCP se diferencia de la llamada a funciones original que OpenAI y sus SDK habilitaron a partir de 2023.

MCP vs. llamada a funciones

Con la llamada a funciones, la aplicación impulsada por IA tenía que implementar cada herramienta. Imagina que una aplicación impulsada por IA como Cursor tuviera que implementar una herramienta de git para “listar ramas remotas”. Una aplicación, como Cursor, podría decidir implementarla ejecutando el comando git ls-remote, mientras que otra aplicación de IA, como Windsurf, podría optar por usar la API de GitHub. Estos dos enfoques ofrecerían experiencias de desarrollo completamente distintas, con diferentes maneras de manejar los errores, entre otras cosas.

Esta falta de organización y estandarización en la capacidad de llamada a funciones provocó una duplicación innecesaria de código y lógica entre las distintas aplicaciones impulsadas por IA.

En resumen, estos son algunos de los valores que diferencian a MCP de la llamada a funciones tradicional:

• Las herramientas de los SDK de llamada a funciones estaban estrechamente integradas con el LLM, por lo que:

• No hay escalabilidad lista para usar; con MCP, en cambio, puedes implementar el servidor MCP y escalarlo de forma independiente de tus aplicaciones de IA.

• No hay una separación clara de responsabilidades entre la implementación de una herramienta en la aplicación de IA y el resto de la lógica de esa aplicación. Son una misma cosa. Técnicamente, puedes crear capas de abstracción e interfaces entre ambas y exponerlas mediante JSON-RPC, pero en ese caso estarías recreando MCP. Eso es lo que ofrece MCP, y mucho más.

• No hay una forma sencilla de permitir que los usuarios que consumen o administran la integración del LLM amplíen las herramientas. Como la implementación de la llamada a funciones forma parte de la integración del LLM, está estrechamente integrada. Para permitir que se amplíen las herramientas de terceros, tendrías que reinventar MCP.

La naturaleza estrechamente integrada de la llamada a funciones tradicional, que se introdujo inicialmente para definir herramientas, también plantea problemas de seguridad. Las operaciones potencialmente peligrosas y delicadas que deben implementar las herramientas forman parte de la aplicación de IA que las proporciona. Una convención de codificación insegura o una práctica de seguridad deficiente en el nivel de las herramientas podría comprometer toda la aplicación de IA.

Además de estandarizar las especificaciones, MCP proporciona una especie de inversión de control (IoC) que desacopla la llamada a funciones y las capacidades ampliadas en servicios separados.

¿MCP es solo una capa para API REST?

Quienes reducen MCP a las API REST tradicionales pasan por alto las complejidades que implica crear aplicaciones de IA. Muchas propiedades de MCP son similares a las de las API REST. MCP se comunica mediante HTTP. El formato subyacente del protocolo es JSON-RPC. Sigue un modelo cliente-servidor. De hecho, se parece mucho a las aplicaciones web tradicionales y su propósito es atender navegadores del lado del cliente y otros clientes que consumen API.

Sin embargo, MCP suele utilizarse con un nivel de granularidad distinto al de las API REST simples y requiere capacidades nativas de IA que las API REST no tienen:

1. Los MCP impulsan casos de uso, no operaciones: Es decir, piensa en los MCP como facilitadores de casos de uso que buscan resolver un problema. Los endpoints de las API REST suelen representar de forma granular las entidades y su entorno. Los MCP terminan creando una matriz TxE (herramientas × endpoints), en la que una sola implementación de herramienta expuesta se asigna a varios endpoints de API REST. Por ejemplo, un servidor MCP que expone una herramienta “get_open_issues” para un repositorio Git probablemente tendría que consultar varios endpoints de API REST: 1) listar todos los issues abiertos; 2) obtener todos los datos y metadatos de cada ID de referencia de un issue abierto. Los servidores MCP suelen ser menos granulares que una API RESTful.

2. Los MCP activan acciones más allá de la web: Aunque es fácil pensar que todo está conectado a la web, muchas demostraciones increíbles de MCP se han centrado en interacciones que no usan la web ni las API REST. Por ejemplo, la popular demostración de Blender MCP, que permitió que la aplicación de IA Claude creara escenas 3D completas, se basó en la API de Python de Blender. Ofrecer el caso de uso de Blender mediante una API nativa del lenguaje permite aprovechar la capacidad de razonamiento de código del LLM para obtener mejores resultados.

3. Los MCP aprovechan los LLM de forma nativa; las API REST no: La especificación de MCP define una capacidad llamada muestreo, que permite que el servidor MCP consulte al LLM para realizar una operación específica. Aquí tienes un ejemplo práctico que es posible con los MCP, pero no con las API existentes, retomando el ejemplo anterior de Git: “obtener los issues abiertos con mayor impacto en la seguridad”. ¿Cómo resolvería una API REST el requisito de “mayor impacto en la seguridad”? Si no hay un filtro o una etiqueta relacionada con seguridad en los issues, no hay forma de obtener la información pertinente. Sin embargo, con los MCP, la implementación de una herramienta obtiene la lista de issues abiertos y envía una solicitud de muestreo al LLM con una instrucción como “de los siguientes issues abiertos, devuelve una lista ordenada según su impacto en la seguridad, en formato JSON”. El LLM puede hacer lo que mejor sabe y ofrecer un resultado con un análisis profundo. El MCP aprovechó un LLM como parte de la solución, algo que no está disponible de forma nativa en una implementación de API REST existente. El muestreo y la comunicación bidireccional con LLM ofrecen mucho más que análisis de similitud o de sentimientos: también aprovechan las fortalezas multimodales de los LLM y permiten mejoras iterativas.

Problemas de seguridad de MCP

MCP también plantea problemas de seguridad. En esencia, la ubicuidad de los servidores MCP genera preocupaciones sobre la seguridad de la cadena de suministro, como las siguientes:

1. Servidores MCP maliciosos: ¿Cómo puedes confiar en un servidor MCP? ¿Qué pasa si el servidor MCP ejecuta código en secreto y extrae información confidencial de tu entorno local o de producción? ¿Podría el servidor MCP alojar una puerta trasera? ¿Cómo puedes validar que no existan estos riesgos de seguridad?

2. Servidores MCP vulnerables: Puede que los servidores MCP funcionen según lo esperado, pero eso no significa que estén libres de vulnerabilidades de seguridad y errores de codificación segura. Una práctica de codificación insegura en un servidor MCP puede ser explotada por quienes lo usan y provocar una vulneración de la seguridad o una filtración de datos.

Estos son solo algunos de los problemas de seguridad relacionados con MCP. Los riesgos de seguridad relacionados con MCP y la IA también abarcan vulnerabilidades de seguridad prácticas del vibe coding, cómo se puede usar un LLM como arma mediante la inyección de prompts y los riesgos de seguridad de programar con ChatGPT.

Todos estos problemas de seguridad de IA, y muchos más, hacen necesarias las medidas de protección de seguridad de IA y la protección del código generado por IA que Snyk ayuda a mitigar.