Entendiendo la Arquitectura MCP

El Problema que MCP Resuelve

Antes de MCP, cada aplicación de IA tenía que construir su propia capa de integración. ¿Quieres que Claude lea tu base de datos? Escribe código custom. ¿Quieres que GPT acceda a tu API? Escribe código custom diferente. Cada combinación de modelo y herramienta requería una implementación única. Este era el problema N x M — N modelos por M herramientas, cada uno necesitando un conector a medida.

El Model Context Protocol (MCP) resuelve esto proporcionando un estándar abierto y único para conectar modelos de IA con herramientas y fuentes de datos externas. Piensa en ello como USB-C para IA: una interfaz universal que cualquier modelo puede usar para hablar con cualquier herramienta.

El Modelo Cliente-Servidor

MCP sigue una arquitectura cliente-servidor. El host es la aplicación con la que el usuario interactúa (Claude Desktop, un IDE, una app custom). Dentro del host, un MCP client mantiene una conexión con uno o más MCP servers. Cada server expone capacidades que el modelo de IA puede usar.

Usuario → Host (Claude Desktop) → MCP Client → MCP Server → Sistema Externo

Esta separación significa que construyes tu MCP server una vez y funciona con cualquier host compatible con MCP. Sin vendor lock-in.

Las Tres Primitivas

MCP define tres primitivas core que los servers pueden exponer:

Tools son acciones que el modelo puede ejecutar — llamar una API, ejecutar una consulta, crear un archivo. Los tools son la primitiva más común. Tienen un nombre, una descripción y un schema de entrada tipado definido con JSON Schema (o Zod en TypeScript).

Resources proporcionan datos que el modelo puede leer — archivos, registros de bases de datos, respuestas de APIs. A diferencia de los tools, los resources están pensados para acceso de datos de solo lectura. Usan direccionamiento basado en URI (file:///ruta o custom://identificador).

Prompts son plantillas reutilizables que ayudan a los usuarios a interactuar con las capacidades del server. Definen flujos de trabajo estructurados — un prompt podría combinar llamadas a tools específicos con contexto para lograr una tarea común.

Capas de Transporte

MCP soporta múltiples mecanismos de transporte:

• stdio: Comunicación a través de entrada/salida estándar. Ideal para servers locales ejecutándose como procesos hijo. El transporte más simple y común.
• Streamable HTTP: Server-Sent Events sobre HTTP para servers remotos. Permite MCP servers alojados en la nube accesibles por red.

La capa de transporte está abstraída — la lógica de tu server se mantiene igual sin importar cómo esté conectado.

Por Qué MCP Ganó

MCP fue creado por Anthropic y rápidamente ganó adopción universal. La Linux Foundation ahora aloja la especificación. Los principales actores lo han adoptado: OpenAI, Google, Microsoft, Amazon y todo el ecosistema de herramientas IA.

Las razones son claras: MCP es simple (tres primitivas cubren la mayoría de casos de uso), componible (los servers se pueden combinar libremente) y seguro (los servers corren en entornos controlados con exposición explícita de capacidades).

Compara esto con raw function calling, donde embeds las definiciones de tools directamente en tus prompts. Function calling funciona para casos simples, pero MCP te da descubrimiento, conexiones stateful, manejo de errores apropiado y un ecosistema estandarizado de servers reutilizables.

Qué Significa Esto para Ti

Como desarrollador, MCP significa que construyes tu integración una vez como MCP server, y cada herramienta IA del ecosistema puede usarla. Como líder técnico, significa que puedes crear un toolkit compartido de MCP servers que todo tu equipo aprovecha — un tema que exploraremos a lo largo de este curso.