MCP (Model Context Protocol)

1. Visión general del concepto y problema sistémico

Antes de la aparición del protocolo MCP, el ecosistema de herramientas de agentes sufría de la clásica problemática de incompatibilidad $N \times M$:

1. Fragmentación de adaptadores: Si tienes 5 clientes de IA (Cursor, Claude Desktop, Continue, agente CLI interno, interfaz web) y 10 fuentes de datos (PostgreSQL, GitHub, Slack, Sentry, sistema de archivos local), los ingenieros debían crear y mantener 50 conectores de integración separados.
2. Filtración de claves sensibles: Las aplicaciones cliente requerían la transmisión de tokens API directos en su contexto, aumentando la superficie de ataque.
3. Falta de tipificación unificada de recursos: No existía un estándar sobre cómo el modelo debía recibir datos pasivos (documentos para lectura) por separado de acciones activas con efectos secundarios (mutaciones en la base de datos).

Model Context Protocol (MCP) resuelve este problema por analogía con el Language Server Protocol (LSP) en el mundo de las IDE: es el "USB-C para inteligencia artificial", que unifica la interacción entre clientes de IA y herramientas de backend a través de un protocolo abierto JSON-RPC 2.0.

2. Taxonomía arquitectónica y modelo mental

El protocolo MCP se basa en una clara distribución cliente-servidor y opera con tres primitivos principales:

• 1. Tools (Herramientas activas con efectos secundarios): Funciones ejecutables que el modelo puede invocar para cambiar el estado del mundo exterior (ejecución de una consulta SQL, inicio de un build, envío de un comentario en GitHub). Se describen a través de un esquema estricto de JSON Schema.
• 2. Resources (Fuentes de datos pasivas para lectura): Datos direccionados por URI sin efectos secundarios, que se transmiten al contexto del modelo como documentos (contenido de archivos, logs del servidor, esquema de tablas, documentación).
• 3. Prompts (Plantillas de interacción): Prompts y cadenas contextuales preparametrizadas que el servidor ofrece al cliente (por ejemplo, una instrucción lista para auditoría de vulnerabilidades o generación de migraciones).
• 4. Capa de transporte (Transport Layer):
  • stdio: ejecución del servidor como un proceso hijo en la misma máquina. No requiere puertos de red, tiene un overhead de latencia nulo.
  • SSE (Server-Sent Events): operación a través de HTTP/HTTPS, que permite conectar microservicios corporativos remotos y agentes en la nube.

3. Pipeline técnico y mecánica interna

El ciclo de vida de una sesión bajo el protocolo MCP pasa por 4 etapas:

1. Handshake & Capabilities Negotiation (Intercambio de capacidades): El cliente envía una solicitud initialize, declarando sus capacidades (por ejemplo, soporte para notificaciones o carpetas raíz). El servidor responde con una lista de sus capacidades (Tools, Resources, Prompts) y la versión del protocolo.
2. Dynamic Discovery (Descubrimiento dinámico): El cliente solicita manifiestos a través de tools/list o resources/list. Las descripciones de funciones y parámetros obtenidas se traducen automáticamente al formato Function Calling para la LLM objetivo.
3. Execution & Context Invocation (Invocación de acción): Cuando el modelo genera una llamada a función, el cliente la traduce en una solicitud tools/call al servidor MCP correspondiente con parámetros JSON validados.
4. Result Streaming & State Notification (Devolución de resultados): El servidor ejecuta la acción localmente, utilizando sus propias configuraciones seguras (sin transmitir contraseñas al cliente), y devuelve el resultado en formato de texto, imágenes o recursos embebidos.

4. Escenarios prácticos de ingeniería en producción

01. Acceso seguro a bases de datos en producción

Un servidor MCP para PostgreSQL se ejecuta dentro de un contorno VPC cerrado. Solo abre para Cursor o Claude Code la herramienta execute_read_only_query. El agente puede analizar el esquema y optimizar consultas lentas, sin tener acceso directo a la contraseña de la base de datos ni derechos de eliminación de datos.

02. Herramientas locales unificadas para desarrolladores

Un servidor MCP escrito una vez para interactuar con GitLab corporativo, Jira interna y el servicio de métricas Datadog se conecta simultáneamente a la terminal CLI (Claude Code), editor gráfico (Cursor) y acciones automatizadas de GitHub.

03. Automatización de navegador con Puppeteer/Playwright

El servidor MCP controla un navegador sin cabeza, proporcionando al cliente herramientas navigate_to, click_element, take_screenshot. El agente prueba interfaces y valida diseños sin necesidad de conectar pesados plugins externos.

5. Errores comunes, trampas y seguridad

• Desbordamiento del contexto (Context Bloat): Conectar 15 servidores MCP con un centenar de esquemas JSON detallados puede consumir más de 30,000 tokens antes de que el usuario introduzca la primera palabra. Utiliza filtrado dinámico o carga perezosa de herramientas (Dynamic Tool Selection).
• Riesgo de servidores externos (Arbitrary Code Execution): Un servidor MCP local se ejecuta con plenos derechos de tu cuenta de sistema operativo. Ejecutar servidores no verificados a través de npx -y sin revisar el código fuente puede llevar al robo de claves SSH locales.
• Violación del contrato del protocolo a través de logging: Usar console.log() o print() estándar dentro del código del servidor corrompe el canal stdout en el transporte stdio. Escribe diagnósticos exclusivamente en stderr.