Model Context Protocol (MCP) estandariza una frontera que, de otro modo, cada sistema de IA con herramientas tendría que inventar: cómo describe las capacidades disponibles, se conecta, las invoca, devuelve resultados y mantiene el control del usuario. 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 archivos locales sin diseñar un formato nuevo para cada pareja.
La arquitectura host-cliente-servidor
La arquitectura oficial separa tres funciones. Sus nombres pueden parecer intercambiables al principio, pero cada una tiene una responsabilidad diferente:
| Función | Qué controla | Responsabilidades habituales |
|---|---|---|
| Host MCP | La aplicación de IA que usa la persona | Integración con el modelo, consentimiento, autorización, agregación de contexto, políticas y experiencia general. |
| Cliente MCP | Una conexión con estado hacia un servidor | Inicialización, negociación del protocolo, enrutamiento, notificaciones, suscripciones y aislamiento de la conexión. |
| Servidor MCP | Un conjunto enfocado de capacidades externas | Exponer herramientas, recursos y prompts respetando los permisos y la frontera de seguridad del servidor. |
Un host puede conectarse con varios servidores, pero crea una instancia de cliente separada para cada uno. Esa relación uno a uno entre cliente y servidor ayuda a mantener diferenciadas las sesiones y las fronteras de seguridad. Un servidor de repositorios no obtiene automáticamente credenciales o datos de un servidor de base de datos solo porque el mismo host utilice ambos.
Qué ocurre durante una conexión MCP
- El host selecciona e inicia una conexión. Un servidor local puede ejecutarse como proceso hijo; uno remoto puede estar disponible mediante HTTPS.
- Cliente y servidor inicializan la sesión. Intercambian versiones del protocolo, información de implementación y capacidades declaradas.
- El host descubre las primitivas disponibles. Según lo negociado, puede enumerar herramientas, recursos o prompts.
- El usuario o el modelo solicita una operación. El host aplica su política de permisos y confirmación antes de reenviar una petición válida.
- El servidor devuelve un resultado o un error. Los resultados pueden ser estructurados o no estructurados e incluir texto, imágenes, audio o enlaces a recursos cuando la especificación lo permite.
- Las notificaciones mantienen el estado actualizado. Las implementaciones pueden anunciar cambios de listas, progreso, cancelación y otros eventos negociados.
La negociación de capacidades es importante porque MCP evoluciona. Un cliente no debe asumir que todos los servidores implementan cada función opcional, y un servidor no debe enviar una solicitud que el cliente nunca declaró compatible.
Herramientas, recursos y prompts no son lo mismo
Herramientas: operaciones que el modelo puede invocar
Una herramienta MCP tiene nombre, descripción legible y esquema de entrada. También puede declarar un esquema de salida y anotaciones de comportamiento. Puede consultar un servicio, crear un ticket, inspeccionar un archivo o realizar otra operación.
Las descripciones y anotaciones ayudan al host a presentar opciones, pero la especificación actual indica que los clientes deben considerar no confiables las anotaciones salvo que procedan de un servidor de confianza. Una etiqueta como “solo lectura” no demuestra que una implementación desconocida carezca de efectos secundarios.
Recursos: contexto que la aplicación puede leer
Los recursos representan datos que pueden entrar en el contexto del modelo: un documento, el esquema de una base de datos, un archivo del repositorio, estado de la aplicación u otro elemento direccionable. Los servidores pueden exponer recursos individuales y plantillas URI, además de admitir suscripciones cuando el contenido cambia.
Un recurso no es simplemente una herramienta sin argumentos. Expresa datos de contexto que la aplicación puede descubrir y leer; una herramienta expresa una operación que el modelo puede solicitar.
Prompts: plantillas reutilizables de interacción
Los prompts son plantillas de mensajes o flujos proporcionados por el servidor, a menudo con argumentos. Suelen estar controlados por el usuario: una interfaz podría mostrar “Revisar este pull request” o “Resumir este incidente” como acción reutilizable. El host obtiene los mensajes resultantes y decide cómo presentarlos o usarlos.
Funciones del cliente: solicitudes en sentido contrario
MCP también define capacidades que un servidor puede solicitar al cliente cuando se han negociado, entre ellas muestreo del modelo, obtención de datos del usuario y registro. Esto no concede acceso ilimitado al modelo ni al usuario. El host sigue siendo responsable de políticas, consentimiento y de la información que cruza la frontera.
stdio local y Streamable HTTP remoto
La capa de datos utiliza mensajes JSON-RPC 2.0. La capa de transporte decide cómo viajan:
- stdio conecta procesos locales mediante entrada y salida estándar. Es directo y no añade transporte de red. Los mensajes del protocolo deben ocupar stdout; los diagnósticos pertenecen a stderr para no corromper el flujo.
- Streamable HTTP usa HTTP POST para los mensajes del cliente al servidor y puede usar Server-Sent Events para streaming. Se adapta a servicios remotos y exige las disciplinas normales de HTTPS, validación de origen, autenticación cuando corresponda y sesiones reforzadas.
“Local” y “seguro” no son sinónimos. Un proceso local se ejecuta con una identidad del sistema operativo y todavía 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 los scopes, archivos, red o cuentas necesarios.
- Política por operación. Aprobar una conexión no autoriza en bloque todas las acciones destructivas o externas futuras.
- Validación de entrada y salida. Valida argumentos según el esquema y trata la salida del servidor como datos no confiables, sobre todo antes de enviarla a otro servidor.
- Aislamiento de credenciales. Mantén tokens fuera del contexto del modelo y de los logs. En autorización remota, valida la audiencia y nunca reenvíes sin cambios a una API ascendente el token recibido del cliente.
- 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.
Para autorización basada en HTTP, la especificación actual se apoya en estándares OAuth y metadatos de recursos protegidos. Los requisitos exactos cambian conforme avanza la especificación, así que conviene usar el documento vigente y bibliotecas mantenidas en vez de copiar un flujo antiguo en código propio.
Cuándo conviene usar MCP
MCP resulta atractivo cuando un host de IA necesita descubrir capacidades de varios servidores mantenidos de forma independiente, presentar una experiencia de integración consistente o conectarse a servicios remotos mediante un protocolo común. También encaja cuando herramientas, recursos, prompts, notificaciones y negociación del ciclo de vida pertenecen al mismo límite.
Una API directa puede ser 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 también 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 versión corta: la interfaz debe corresponder a la frontera real, no a la sigla que recibe más atención.
Dónde encaja QZX
QZX (Quick Zap Exchange) es actualmente una CLI, no un servidor MCP. Los agentes con terminal pueden descubrir sus comandos, invocarlos como procesos y solicitar JSON estructurado. Cada comando público está diseñado para devolver al menos success y message, además de campos de dominio.
Un adaptador MCP podría exponer como herramientas un subconjunto seleccionado de comandos QZX. Un adaptador responsable no publicaría todos los comandos a ciegas: mapearía esquemas de entrada explícitos, conservaría los resultados JSON, mantendría requisitos de aprobación y respaldo, aislaría privilegios y distinguiría claramente lecturas y mutaciones.
Host del agente
└─ Cliente MCP
└─ Servidor MCP enfocado
└─ Comando QZX seleccionado --jsonEsa composición puede ser útil, pero añade otro proceso y otra frontera de políticas. Cuando el host ya tiene terminal y existe un comando QZX documentado para la tarea, el uso directo de la CLI puede continuar siendo la opción más económica.
Lista práctica de evaluación
- ¿Mantiene el servidor una parte en la que confías y puedes revisar qué expone?
- ¿Sus herramientas, recursos y prompts están enfocados en vez de ser innecesariamente amplios?
- ¿El host muestra consentimiento claro para acceso a datos y acciones importantes?
- ¿Están limitados tokens, archivos, destinos de red y privilegios del sistema?
- ¿La implementación usa bibliotecas MCP mantenidas y la especificación vigente?
- ¿Puedes probar fallos, timeout, cancelación, salida inválida y efectos parciales?
- ¿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 que estandariza cómo las aplicaciones de IA se conectan con herramientas externas, recursos de datos y prompts reutilizables mediante sesiones cliente-servidor.
¿Qué diferencia hay entre host, cliente y servidor MCP?
El host controla la experiencia y las políticas de IA. Crea un cliente para cada conexión con estado hacia un servidor. El servidor expone un conjunto enfocado de capacidades externas.
¿Qué son las herramientas, recursos y prompts en MCP?
Las herramientas son operaciones que el modelo puede invocar, los recursos aportan datos de contexto y los prompts son plantillas reutilizables de mensajes o flujos presentadas por el host.
¿Qué transportes utiliza MCP?
La arquitectura actual documenta stdio para comunicación directa entre procesos locales y Streamable HTTP para comunicación remota o por red, con Server-Sent Events opcionales para streaming.
¿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. Un servidor MCP podría envolver comandos QZX seleccionados, pero tendría que conservar su validación, permisos, seguridad y contratos de resultado estructurado.