Saltar al contenido principal

Agentes de IA · Protocolos abiertos

¿Qué es Model Context Protocol (MCP) en 2026? Arquitectura sin estado, herramientas, transporte y seguridad

Model Context Protocol ofrece a las aplicaciones de IA una forma común de conectarse con capacidades externas. La especificación 2026-07-28 cambia una parte importante del modelo mental: el núcleo del protocolo ahora es sin estado, cada solicitud se describe a sí misma y los resultados de herramientas pueden transportar contenido estructurado validado por esquema.

Por Alejandro Sánchez, creador de QZX 14 min de lectura
Un host central de IA se conecta mediante canales de cliente separados con módulos de servidor que representan herramientas, recursos y prompts reutilizables.
Un host coordina instancias de cliente aisladas para servidores MCP enfocados. En MCP 2026-07-28 el protocolo es sin estado aunque las aplicaciones todavía puedan gestionar estado explícito.

Model Context Protocol (MCP) estandariza una frontera que, de otro modo, cada sistema de IA con herramientas tendría que inventar: cómo describe capacidades disponibles, las invoca, devuelve resultados, intercambia contexto y mantiene las decisiones de seguridad en el host. No define un modelo, proveedor, lenguaje de programación ni base de datos concretos.

Esa diferencia importa. MCP no es un directorio de todas las herramientas de IA, un agente automático ni un sandbox de seguridad. Es un protocolo. Las implementaciones pueden usarlo para conectar un asistente de programación con un servicio de repositorios, un agente de soporte con un sistema de tickets o una aplicación de escritorio con herramientas locales sin diseñar un formato nuevo para cada pareja.

La arquitectura host-cliente-servidor continúa — pero el protocolo es sin estado

La arquitectura actual conserva tres funciones. Lo que cambió no es la existencia de hosts, clientes y servidores, sino dónde vive el estado del protocolo. Cada solicitud es autocontenida y transporta su versión del protocolo y capacidades del cliente.

Función Qué controla Responsabilidades habituales en 2026-07-28
Host MCP La aplicación de IA que usa la persona Integración con el modelo, consentimiento, decisiones de autorización, agregación de contexto, políticas y gestión de varias instancias de cliente.
Cliente MCP Comunicación con exactamente un servidor Adjuntar metadata de protocolo y capacidades a las solicitudes, enrutar mensajes, gestionar suscripciones y notificaciones y preservar la frontera de seguridad entre servidores.
Servidor MCP Un conjunto enfocado de capacidades externas Exponer herramientas, recursos y prompts; anunciar capacidades; devolver resultados completos o que requieren input; respetar su frontera de seguridad.

Un host puede gestionar varios clientes y cada cliente se comunica con un servidor concreto. Esa relación uno a uno sigue siendo útil para aislamiento, pero ya no implica una sesión a nivel de protocolo. Un servidor de repositorios no obtiene automáticamente credenciales o datos de otro servidor solo porque el mismo host pueda usar ambos.

¿Qué ocurre ahora durante una solicitud MCP?

  1. El host elige un servidor y una instancia de cliente. Un servidor local puede ejecutarse como proceso hijo; uno remoto puede estar disponible mediante Streamable HTTP.
  2. La solicitud transporta su propia metadata de protocolo. El modelo 2026-07-28 incluye versión, identidad del cliente y capacidades en metadata de cada solicitud en vez de depender de un intercambio de inicialización previo.
  3. El descubrimiento es opcional para el cliente. Puede llamar primero a server/discover para conocer versiones, capacidades e identidad del servidor, o invocar otro RPC directamente y gestionar un error de versión.
  4. El cliente enumera o invoca una capacidad. Las listas de herramientas, recursos y prompts son deterministas y pueden incluir hints de caché. Una llamada de herramienta incluye nombre, argumentos y metadata de la solicitud.
  5. El servidor devuelve un resultado completo o pide más datos. Un resultado completado usa resultType: "complete". Si necesita información adicional, Multi Round-Trip Requests puede devolver resultType: "input_required" y el cliente reintenta con las respuestas solicitadas.
  6. Suscripciones y cancelación tienen comportamiento explícito por transporte. El protocolo moderno no depende de mantener una sesión bidireccional permanentemente abierta para soportar eventos de ciclo de vida.

Esto importa en operación. Las solicitudes sin estado pueden atenderse con infraestructura horizontal común sin sesiones sticky del protocolo ni un almacén compartido de sesiones. La aplicación puede seguir teniendo estado, pero conviene volverlo explícito: por ejemplo, una herramienta puede devolver un identificador de carrito, navegador o transacción que se envía de nuevo en llamadas posteriores.

Herramientas, recursos y prompts no son lo mismo

Herramientas: operaciones que el modelo puede invocar

Una herramienta MCP tiene nombre, descripción y un esquema de entrada JSON Schema. En 2026-07-28 los esquemas de herramientas usan JSON Schema 2020-12 por defecto. Una herramienta también puede declarar outputSchema, y un resultado completado puede devolver structuredContent que debe cumplir ese esquema cuando se declara.

structuredContent puede ser cualquier valor JSON permitido por el esquema. Para retrocompatibilidad MCP recomienda repetir una representación serializada en un bloque de texto. Descripciones y anotaciones siguen necesitando un modelo de confianza: un cliente no debe interpretar una etiqueta como “solo lectura” de un servidor no confiable como prueba de comportamiento.

Recursos: contexto que la aplicación puede leer

Los recursos representan contexto direccionable como documentos, archivos de repositorio, esquemas de bases de datos o estado de una aplicación. Los servidores pueden exponer recursos individuales y plantillas URI. Un recurso no es simplemente una herramienta sin argumentos: representa datos que la aplicación puede descubrir y leer, no una operación que el modelo solicita.

Prompts: plantillas reutilizables de interacción

Los prompts son plantillas o flujos reutilizables proporcionados por el servidor, a menudo con argumentos. Pueden ofrecer al host una forma consistente de presentar acciones como “Revisar este pull request” o “Resumir este incidente” sin quitar al host el control de presentación y política del modelo.

Multi Round-Trip Requests reemplaza la antigua suposición de RPC iniciados por el servidor

El núcleo 2026-07-28 ya no depende de que los servidores inicien solicitudes JSON-RPC mediante una sesión del protocolo mantenida abierta. Cuando una herramienta necesita datos adicionales del usuario o cliente, Multi Round-Trip Requests permite devolver un resultado que requiere input y que el cliente reintente la operación original con respuestas explícitas.

Roots, Sampling y Logging a nivel de protocolo están deprecados desde 2026-07-28. Siguen disponibles durante la ventana de deprecación por compatibilidad, pero los diseños nuevos no deberían basar su arquitectura en esas funciones. Es un buen ejemplo de por qué la documentación sobre MCP debería nombrar la revisión de especificación que describe.

stdio y Streamable HTTP en el protocolo sin estado

MCP utiliza mensajes JSON-RPC; el binding de transporte define el framing y la entrega:

  • stdio usa mensajes delimitados por líneas sobre los streams estándar de un subproceso iniciado por el cliente. La salida del protocolo pertenece a stdout y los diagnósticos normales a stderr.
  • Streamable HTTP envía cada mensaje mediante HTTP POST a un único endpoint MCP. La respuesta puede ser un objeto JSON o un stream de Server-Sent Events limitado a esa solicitud. La metadata de protocolo permanece en el cuerpo y ciertos valores se reflejan en headers —versión, método y nombre de herramienta— para que la infraestructura pueda enrutar o inspeccionar solicitudes sin parsear JSON.

La distinción importante de 2026 es lo que ya no se exige: una solicitud remota no depende de la antigua sesión de protocolo Mcp-Session-Id. Esto elimina una razón para sticky routing. No elimina autenticación, estado de aplicación, autorización, observabilidad, timeouts ni una gestión cuidadosa de recursos.

“Local” y “seguro” no son sinónimos. Un proceso local se ejecuta con una identidad del sistema operativo y puede acceder a archivos valiosos o realizar operaciones peligrosas. “Remoto” tampoco significa automáticamente público: un servidor remoto puede ser privado y estar fuertemente autorizado.

Seguridad MCP: el protocolo no es el sandbox

MCP puede volver explícitas las fronteras, pero no garantiza que cada servidor, herramienta, entrada o documento devuelto sea confiable. Un diseño de producción debe aplicar varias capas:

  • Consentimiento informado. Explica qué datos se leerán, qué acción ocurrirá y hacia dónde se enviará información.
  • Mínimo privilegio. Expón el conjunto útil más pequeño y concede solo scopes, archivos, red o cuentas necesarios.
  • Política por operación. Tener acceso a un servidor o catálogo de herramientas no autoriza en bloque todas las acciones destructivas o externas.
  • Validación de entrada y salida. Valida argumentos según sus esquemas y valida resultados estructurados cuando exista outputSchema.
  • Aislamiento de credenciales. Mantén tokens fuera del contexto del modelo y de logs; valida reglas de emisor/audiencia y evita reenviar credenciales a ciegas a servicios ascendentes.
  • Defensas contra prompt injection. Un documento devuelto como recurso puede contener instrucciones hostiles. El contenido no se vuelve confiable por haber llegado mediante MCP.
  • Contención de ejecución. Usa permisos del sistema, sandboxes, controles de red, timeouts, límites de recursos y auditoría según el riesgo.

La versión 2026-07-28 también refuerza autorización y depreca Dynamic Client Registration a favor de Client ID Metadata Documents. Es otra zona donde conviene usar la especificación actual y SDK mantenidos en vez de copiar de un artículo antiguo un flujo OAuth.

¿Cuándo conviene usar MCP?

MCP resulta atractivo cuando un host de IA necesita descubrir capacidades de servidores mantenidos de forma independiente, presentar una experiencia de integración consistente o conectar capacidades locales y remotas mediante un protocolo compartido. La revisión sin estado facilita encajar MCP remoto detrás de infraestructura HTTP escalable común.

Una API directa puede seguir siendo más sencilla cuando una aplicación controla ambos lados y ya dispone de un cliente tipado estable. Una CLI puede ser la frontera más pequeña para automatización local cuando el agente ya tiene terminal. Las opciones se combinan: un servidor MCP puede llamar a una API o envolver una CLI cuidadosamente seleccionada.

Nuestra comparación detallada de MCP vs CLI vs API analiza descubrimiento, transporte, permisos, portabilidad y costo operativo. La pregunta útil no es qué interfaz está de moda, sino qué frontera reduce complejidad sin perder las garantías que necesita la carga de trabajo.

Dónde encaja QZX: MCP puede transportar QZX Result Contract sin convertirse en QZX

QZX (Quick Zap Exchange) es actualmente una CLI, no un servidor MCP. Los agentes con terminal pueden invocarlo directamente y solicitar JSON estructurado. QZX Result Contract v1 define un pequeño contrato de resultado independiente del transporte con success explícito, un message útil y evidencia de dominio aditiva.

Las primitivas útiles de salida estructurada no comenzaron con 2026-07-28: MCP 2025-06-18 ya incluía outputSchema, structuredContent e isError para herramientas. Eso permite que una herramienta MCP ajena conserve nombre, entradas, permisos, runtime y campos de dominio propios mientras adopta la semántica de resultado completado de QZX. Por eso QZX soporta perfiles específicos para 2025-06-18, 2025-11-25 y 2026-07-28 en vez de obligar a un servidor compatible a actualizarse sólo por QZX. MCP sigue siendo el protocolo; QZX Result Contract describe el resultado de la operación completada.

Definición de herramienta MCP
  └─ outputSchema → schema QZX canónico o núcleo estructural revisable

Llamada completada · todas las revisiones soportadas
  ├─ structuredContent → { success, message, ...evidencia }
  └─ isError ↔ !success

Sólo MCP 2026-07-28
  └─ resultType: "complete"

QZX publica validación sin dependencias de terceros y fixtures para los tres perfiles. Las receipts de conformidad también registran si outputSchema incorpora el schema canónico o usa la modalidad más débil y portable entre SDKs structural_core, de modo que la afirmación siga siendo revisable en vez de reducir relaciones distintas del schema a un único indicador verde. El proyecto busca explícitamente su primera implementación o piloto independiente y revisable; QZX no se cuenta a sí mismo como adopción independiente.

Leer el perfil de interoperabilidad QZX + MCP Se busca primera implementación independiente

Lista práctica de evaluación para 2026

  1. ¿Qué revisión de la especificación MCP soporta realmente la implementación?
  2. ¿Entiende el modelo de solicitudes sin estado de 2026-07-28 o usa intencionalmente un handshake antiguo por retrocompatibilidad?
  3. ¿Mantiene el servidor una parte en la que confías y puedes revisar qué expone?
  4. ¿Sus herramientas, recursos y prompts están enfocados en vez de ser innecesariamente amplios?
  5. ¿El host muestra consentimiento claro para acceso a datos y acciones importantes?
  6. ¿Se validan realmente los esquemas de entrada y los esquemas de salida declarados?
  7. ¿Puedes probar por separado éxito, errores de ejecución de herramienta, errores de protocolo, timeout, cancelación y flujos que requieren input?
  8. ¿Una API directa o CLI resolvería el mismo problema con menos piezas?

Preguntas frecuentes

¿Qué es Model Context Protocol?

Model Context Protocol, o MCP, es un protocolo abierto cliente-host-servidor que conecta aplicaciones de IA con herramientas, recursos, prompts y capacidades relacionadas mediante un modelo común de mensajes. En la revisión 2026-07-28 el núcleo es sin estado y cada solicitud lleva su propia metadata de protocolo y capacidades del cliente.

¿MCP eliminó clientes y servidores al volverse sin estado?

No. Los hosts siguen gestionando instancias de cliente y cada cliente se comunica con un servidor. “Sin estado” significa que el protocolo ya no depende del antiguo handshake de inicialización y una sesión de protocolo para las solicitudes posteriores.

¿Qué reemplazó al handshake initialize de MCP?

Cada solicitud incluye ahora versión del protocolo, identidad del cliente y capacidades en su metadata. Un cliente puede llamar primero a server/discover para conocer versiones y capacidades del servidor, pero ese descubrimiento es opcional para el cliente.

¿Qué son outputSchema y structuredContent?

Una herramienta MCP puede declarar un outputSchema JSON Schema. Cuando lo hace, el servidor debe devolver structuredContent que lo cumpla. En 2026-07-28 el esquema usa JSON Schema 2020-12 por defecto y el contenido estructurado puede ser cualquier valor JSON permitido por ese esquema.

¿Qué transportes utiliza MCP?

Los bindings estándar son stdio para subprocesos locales iniciados por el cliente y Streamable HTTP para comunicación de red. Streamable HTTP usa un endpoint MCP y comportamiento HTTP/SSE limitado a cada solicitud en vez de exigir una sesión de protocolo.

¿MCP vuelve seguras automáticamente las herramientas de IA?

No. MCP es una interfaz, no un sandbox. La implementación todavía necesita consentimiento, mínimo privilegio, autorización, validación, aislamiento, credenciales seguras y defensas contra prompt injection.

¿QZX es un servidor MCP?

No. QZX es actualmente una CLI. Por separado, QZX Result Contract v1 puede utilizarse como esquema del resultado completado dentro de una herramienta MCP sin convertir esa herramienta en QZX.

Fuentes primarias y lecturas adicionales