Agent Skills frente a MCP: cómo elegir la interfaz adecuada
Agent skills frente a MCP: compara instrucciones, conexiones de herramientas, límites de seguridad, versionado y cuándo combinar ambos para crear agentes de IA fiables.
La decisión entre agent skills y MCP suele plantearse como una competición entre dos formas de «darle herramientas a una IA». Ese planteamiento es incompleto. Un skill y un servidor de Model Context Protocol resuelven capas distintas del problema: uno enseña al agente a operar en un dominio, mientras que el otro expone capacidades y contexto mediante una conexión estandarizada.
Dockup usa un SKILL.md porque su interfaz principal es una herramienta de línea de comandos existente. El skill enseña a Claude Code y Codex a utilizar esa CLI de forma segura: solicitar siempre JSON, autenticarse sin interacción, resolver destinos exactos, esperar a los estados terminales del despliegue y detenerse antes de realizar operaciones destructivas.
¿Qué es un agent skill y por qué es importante SKILL.md?
Un agent skill es un directorio de instrucciones operativas y referencias de apoyo que un agente puede cargar cuando una tarea coincide con el propósito del skill. SKILL.md es el punto de entrada: sus metadatos describen la capacidad y el cuerpo explica los workflows, las restricciones, los ejemplos y las reglas de decisión.
Un skill resulta especialmente útil cuando la interfaz ejecutable ya existe. El agente no necesita un nuevo adaptador de protocolo simplemente para ejecutar una CLI bien diseñada. Necesita información precisa sobre:
- Qué comandos son la fuente de verdad.
- Qué flags son obligatorios para el uso por parte de máquinas.
- Cómo funciona la autenticación en un sandbox.
- Qué salidas demuestran que una operación se ha completado correctamente.
- Qué acciones requieren intervención humana.
- Dónde pueden aparecer secretos.
- Cómo diagnosticar los fallos habituales.
La instalación de Dockup es intencionadamente sencilla:
npm install -g dockup-cli
dockup skill install
dockup skill status --json
Se escribe una única copia canónica en ~/.agents/skills/dockup/ y se enlaza con Claude Code y Codex. El skill se incluye en el paquete de la CLI, y dockup update los actualiza conjuntamente. Esta decisión de empaquetado evita un fallo habitual: que las instrucciones describan comandos que el binario instalado no tiene.
El skill no es el motor de despliegue. La CLI ejecuta las operaciones, emite JSON y devuelve códigos de salida. El skill es el manual operativo que sigue el agente.
¿Qué es Model Context Protocol?
Model Context Protocol, conocido habitualmente como MCP, es un protocolo abierto para conectar una aplicación de IA con herramientas, recursos y prompts externos mediante una arquitectura cliente-servidor. Un servidor MCP puede exponer tools invocables, resources que se pueden leer y prompts reutilizables. Un cliente MCP dentro del host del agente descubre e invoca esas capacidades.
MCP resulta valioso cuando un sistema necesita un límite de protocolo duradero en lugar de ejecutar comandos localmente en el shell. Algunos ejemplos son:
- Una API SaaS remota que debería exponer operaciones cuidadosamente tipadas.
- Una fuente de datos que proporciona resources navegables.
- Una aplicación de escritorio que quiere descubrimiento de herramientas sin distribuir una CLI.
- Un servicio central utilizado por muchos hosts de agentes y sistemas operativos.
- Una integración en la que el servidor debe gestionar las credenciales y las políticas.
El servidor controla la implementación que hay detrás de cada herramienta. El host del agente ve el nombre declarado, la descripción, el input schema y la salida. El transporte, el ciclo de vida y la autorización dependen de la configuración de MCP elegida.
MCP no proporciona automáticamente criterio de dominio. Un servidor puede exponer delete_service, pero el agente sigue necesitando una política que determine cuándo es apropiado eliminar algo. Del mismo modo, un skill puede explicar un workflow, pero no puede crear capacidades ausentes en la CLI o la API subyacente.
¿En qué se diferencian en la práctica agent skills y MCP?
La comparación más clara se basa en las responsabilidades:
| Dimensión | Agent skill / SKILL.md | Servidor MCP |
|---|---|---|
| Función principal | Enseñar workflows y restricciones | Exponer herramientas, recursos y prompts |
| Ejecución | Utiliza CLI, archivos, APIs o aplicaciones existentes | El servidor implementa capacidades invocables |
| Descubrimiento | El agente carga las instrucciones del skill correspondiente | El cliente descubre las capacidades del servidor |
| Distribución | Normalmente, una carpeta instalada con un paquete | Un proceso de servidor local o remoto |
| Riesgo de versiones | Las instrucciones pueden alejarse de la herramienta | El schema del servidor puede alejarse del comportamiento del backend |
| Mejor uso | Una interfaz existente necesita orientación operativa experta | Una capacidad necesita un límite de protocolo estandarizado |
| Enfoque de seguridad | Reglas de comportamiento y seguridad de los comandos | Conexión, confianza en el servidor, scopes y autorización de herramientas |
| Uso offline/local | Excelente con CLIs locales | Posible con un servidor MCP local |
| Reutilización entre clientes | Copiar o empaquetar el skill para cada host | Un servidor puede admitir varios clientes compatibles |
Ninguna de las dos opciones es intrínsecamente más «agentic». La fiabilidad depende de adaptar la interfaz al sistema.
En el caso de Dockup, la CLI ya cuenta con 135 comandos, JSON estructurado, códigos de salida reales, un timeout de despliegue predeterminado de 900 segundos, ocultación de secretos y confirmation gates. Envolver todos los comandos en otro servidor local añadiría una capa de traducción sin cambiar la realidad subyacente del despliegue. Un skill encaja directamente porque enseña al agente a utilizar el contrato ejecutable que ya existe.
Una plataforma remota sin CLI puede llegar a la conclusión opuesta. Un servidor MCP puede proporcionar la superficie de herramientas tipadas que falta y mantener las credenciales de la API fuera del entorno de shell del agente.
¿Cuándo deberías usar un skill, MCP o ambos?
Usa únicamente un skill cuando se cumplan todas las condiciones siguientes:
- Ya existe una CLI madura o una aplicación local que expone la capacidad necesaria.
- El host del agente tiene permiso para ejecutarla.
- La salida legible por máquinas y la semántica de los códigos de salida son adecuadas.
- La principal carencia es el conocimiento procedimental, no la conectividad.
- El empaquetado puede mantener las instrucciones alineadas con el ejecutable.
Usa únicamente MCP cuando el agente necesite una conexión nativa de protocolo y el propio servidor pueda proporcionar contexto suficiente para operar de forma segura. Es habitual en el acceso a datos con predominio de lecturas, los servicios remotos y las aplicaciones que quieren una interfaz de herramientas estable y común para distintos clientes.
Usa ambos cuando las herramientas del protocolo necesiten un playbook operativo más completo. Un servidor MCP puede exponer primitivas seguras y tipadas, mientras que un skill explica el workflow de negocio con varios pasos, las reglas de escalado y los criterios de validación. El skill puede indicar al agente cuándo y por qué debe llamar a cada herramienta MCP.
Una arquitectura combinada podría tener este aspecto:
Solicitud del usuario
↓
Skill: workflow, política y reglas de validación
↓
Cliente MCP: descubre capacidades tipadas
↓
Servidor MCP: autentica y ejecuta
↓
Sistema externo
Una arquitectura centrada en una CLI es más sencilla:
Solicitud del usuario
↓
Skill: workflow, política y reglas de validación
↓
CLI: salida JSON + código de salida + semántica de espera
↓
API de la plataforma
La complejidad debe estar justificada por un límite que mejore. Añadir MCP únicamente porque está de moda puede crear otro proceso que desplegar, autenticar, supervisar y versionar.
Ejemplos de decisión
| Situación | Mejor punto de partida | Motivo |
|---|---|---|
| CLI de despliegue local con salida JSON | Skill | La conectividad ya existe |
| Base de conocimiento corporativa con recursos estructurados | MCP | El descubrimiento de recursos es central |
| API de administración de bases de datos sin CLI | MCP | Las operaciones remotas tipadas son útiles |
| Runbook de release complejo que coordina herramientas existentes | Skill | El procedimiento entre herramientas es la necesidad principal |
| Operaciones remotas reguladas junto con una política detallada | Ambos | El servidor aplica el scope y el skill guía el comportamiento |
| Automatización personal puntual | Skill o CLI directa | Menor sobrecarga operativa |
La respuesta adecuada puede cambiar con el tiempo. Un equipo puede empezar con un skill basado en una CLI y añadir después un servidor MCP cuando el acceso remoto para varios clientes o la gestión centralizada de credenciales se vuelva importante.
¿Cómo se comparan los límites de seguridad y confianza?
Los skills son instrucciones, por lo que su riesgo de confianza se parece al de una documentación de código con influencia operativa. Un skill malicioso o descuidado puede indicar al agente que exponga secretos, desactive salvaguardas o ejecute comandos destructivos. Revisa el directorio completo, no solo su título.
Al revisar un skill, conviene preguntarse:
- ¿Quién lo ha publicado?
- ¿Invoca comandos ajenos a su propósito declarado?
- ¿Indica al agente que muestre tokens o credenciales?
- ¿Evita las confirmaciones?
- ¿Los ejemplos de comandos proceden de la versión instalada?
- ¿Las actualizaciones pueden sustituir el skill sin revisión?
- ¿Define un proceso acotado para descubrir destinos?
MCP introduce un límite de confianza en el servidor. El cliente debe saber con qué servidor se conecta, qué herramientas expone, qué datos salen de la máquina y cómo se limita el alcance de la autorización. Un servidor puede cambiar su comportamiento detrás de un nombre de herramienta estable, por lo que la procedencia del despliegue y el versionado del servidor son importantes.
Al revisar un MCP, conviene preguntarse:
- ¿El servidor es local o remoto?
- ¿Quién lo opera?
- ¿Cómo se almacenan y rotan las credenciales?
- ¿Qué llamadas a herramientas pueden modificar o eliminar datos?
- ¿Se validan las entradas de las herramientas en el servidor?
- ¿Las salidas se tratan como contenido no fiable?
- ¿Se puede auditar cada llamada?
- ¿Puede el cliente restringir las herramientas disponibles?
El host del agente no debe equiparar «descubierto mediante MCP» con «seguro». La estandarización del protocolo mejora la interoperabilidad, no la fiabilidad de todos los servidores.
El skill de Dockup codifica varias reglas de seguridad: usar DOCKUP_TOKEN en lugar de un inicio de sesión interactivo, no mostrar nunca las credenciales, descubrir destinos con dockup services --json, usar --wait y detenerse ante needs_confirm. La CLI refuerza estas instrucciones ocultando secretos y rechazando operaciones destructivas sin aprobación explícita. Este modelo de defensa en profundidad se describe en guardrails de producción para agentes de IA.
¿Cómo deberían funcionar el versionado y la recuperación ante fallos?
En ambos enfoques puede producirse drift de versiones, aunque se manifiesta de forma distinta.
Un skill puede quedar obsoleto cuando cambia el comando documentado. La mitigación más sólida consiste en empaquetar el skill con el ejecutable y actualizar ambos mediante un único proceso de release. Dockup sigue este modelo. El agente puede comprobar el skill instalado:
dockup skill status --json
Una actualización renueva la CLI y el skill incluido conjuntamente:
dockup update
Un cliente MCP puede descubrir los schemas actuales de las herramientas del servidor, pero la compatibilidad del schema no garantiza la compatibilidad semántica. Una herramienta puede conservar las mismas entradas y cambiar la autorización, los efectos secundarios, la latencia o la interpretación de la salida. El servidor debería publicar versiones, mantener la compatibilidad hacia atrás siempre que sea posible y devolver errores estructurados.
La gestión de fallos también es diferente. Una CLI ofrece códigos de salida de proceso de forma natural. Una llamada a una herramienta MCP necesita un resultado equivalente y claro a nivel de aplicación. En ambos casos, el agente no debe inferir que una operación se ha completado correctamente a partir de un acuse de recibo del transporte.
Una checklist de fiabilidad útil es:
| Requisito | Implementación con skill + CLI | Implementación con MCP |
|---|---|---|
| Descubrimiento de capacidades | Schema de la CLI | Lista de herramientas del servidor |
| Salida estructurada | JSON/NDJSON | Resultado tipado de la herramienta |
| Señal de fallo | Salida distinta de cero + código | Resultado de error explícito |
| Operación prolongada | --wait / stream documentado | Protocolo de progreso o finalización |
| Protección de secretos | Ocultación y disciplina con stderr | Redacción en el servidor |
| Aprobación destructiva | Confirmation gate de la CLI | Política del servidor o confirmación del cliente |
| Auditoría | Log de auditoría de la plataforma | Logs de auditoría del servidor y del backend |
| Comprobación de versión | Estado del skill/binario | Metadatos y schemas del servidor |
La interfaz debe hacer que sea más difícil informar incorrectamente de un fallo que de un éxito.
¿Qué arquitectura debería elegir un equipo de producción?
Empieza por identificar la carencia real.
Elige una arquitectura skill-first cuando el equipo ya confíe en una CLI y la opere. Invierte en su contrato para máquinas: JSON, códigos de salida reales, códigos de error estables, instrucciones alineadas con la versión y confirmación. Después, empaqueta el skill con esa herramienta. Este es el camino más corto para el despliegue con Claude Code y el despliegue integral con Codex mediante Dockup.
Elige MCP-first cuando la capacidad sea naturalmente remota, esté orientada a recursos o se comparta entre muchos clientes. Trata el servidor como software de producción: autentícalo, limita su scope, monitorízalo y revisa cada mutación.
Elige ambos cuando la política y la conectividad sean complejas de forma independiente. Mantén claras las responsabilidades. El skill no debería duplicar la implementación del servidor, y la descripción del servidor no debería convertirse en un manual operativo interminable.
Un workshop práctico de evaluación
Realiza una prueba pequeña con una operación de lectura, una escritura reversible, una operación de larga duración y una operación destructiva que deba bloquearse. Puntúa cada diseño según:
- Cómo descubre el agente la operación.
- Cómo se proporcionan las credenciales.
- Cómo se demuestra el éxito.
- Cómo se categoriza el fallo.
- Cómo aprueba una persona los riesgos.
- Cómo se recuperan los logs y las evidencias de auditoría.
- Cómo se mantienen alineadas las versiones.
- Cómo se elimina la integración correctamente.
No tomes la decisión basándote solo en un diagrama. Observa las rutas de fallo. Un diseño que parece elegante en el happy path puede volverse ambiguo cuando un despliegue agota el tiempo de espera, un servidor se desconecta o un archivo de instrucciones lleva una release de retraso.
La referencia de la CLI de Dockup ofrece un ejemplo concreto de un contrato de CLI respaldado por un skill. El artículo más amplio sobre desarrollo impulsado por IA explica por qué estas interfaces son importantes a medida que los agentes asumen una parte mayor del ciclo de desarrollo.
Ten en cuenta quién se encarga de las operaciones
El responsable de la integración importa tanto como su arquitectura. Un skill basado en una CLI suele heredar el proceso de instalación, release y soporte de esa CLI. El equipo que publica el binario puede distribuir sus instrucciones correspondientes y probarlas conjuntamente.
Un servidor MCP crea un componente de producción independiente. Alguien debe encargarse del hosting, los certificados o el inicio del proceso local, la autenticación, la monitorización, la respuesta a incidentes, la compatibilidad del schema y las actualizaciones de dependencias. Esta inversión puede merecer la pena cuando el servidor constituye un límite compartido importante. Es una sobrecarga innecesaria cuando solo reenvía llamadas locales a un ejecutable que ya es suficiente.
Durante la evaluación, deja por escrito quién es responsable de cada capa:
| Capa | Responsable en skill-first | Responsable en MCP-first |
|---|---|---|
| Instrucciones de dominio | Publicador del skill | Prompt del cliente o skill complementario |
| Comportamiento ejecutable | Publicador de la CLI | Equipo del servidor MCP |
| Gestión de credenciales | CLI y entorno de ejecución | Servidor y conexión del cliente |
| Disponibilidad | Ejecutable local y API de la plataforma | Proceso del servidor, transporte y backend |
| Compatibilidad del schema | Proceso de release de la CLI | Proceso de release del servidor MCP |
| Evidencias de incidentes | Salida de la CLI y auditoría de la plataforma | Logs del cliente, logs del servidor y auditoría del backend |
Esta tabla de responsabilidades suele resolver el debate sobre agent skills y MCP con más claridad que una checklist de funcionalidades.
Evalúa la latencia y las superficies de fallo
Una llamada local con skill y CLI tiene un recorrido corto: host del agente, proceso y API de la plataforma. Una ruta con MCP puede añadir el inicio del servidor, la negociación del transporte, el routing remoto y otra capa de autenticación. Estas adiciones no son necesariamente negativas, pero cada una crea una superficie de fallo distinta.
Prueba las desconexiones, las credenciales caducadas, las entradas con formato incorrecto, las operaciones prolongadas parciales y las actualizaciones del servidor. El agente debe poder indicar si el fallo se produjo en el host, en la conexión del protocolo, en el servidor o en la plataforma externa. Un resultado genérico de «la herramienta ha fallado» no es suficiente para el trabajo de producción.
En los despliegues prolongados, la interfaz debe conservar la semántica de los estados terminales. Tanto si la llamada es una operación de la CLI con --wait como si es una herramienta MCP con progreso, el agente no debe convertir un acuse de recibo en un éxito. La elección entre agent skills y MCP no elimina este requisito.
Planifica la portabilidad sin sacrificar la verdad
MCP puede mejorar la portabilidad entre clientes compatibles porque el mismo servidor anuncia las herramientas mediante un protocolo compartido. Los skills también pueden ser portables cuando varios agentes admiten el mismo directorio y las convenciones de SKILL.md, como Claude Code y Codex en el modelo de instalación de Dockup.
La portabilidad solo es útil si la semántica sigue siendo precisa. Una herramienta llamada deploy debe definir si devuelve el resultado cuando la operación se pone en cola o cuando el servicio está healthy. Una instrucción de skill que diga «despliega y verifica» debe apuntar a un comando que realmente pueda proporcionar esa prueba.
El diseño más sólido mantiene la verdad del dominio cerca de la capa ejecutable y utiliza la capa superior para explicar la intención. En la comparación entre agent skills y MCP, ni un protocolo estandarizado ni un archivo de instrucciones bien redactado compensan una operación de backend ambigua.
Lleva el workflow a producción
Utiliza la arquitectura más pequeña que cree un límite fiable. En el caso de Dockup, instala el skill incluido en el paquete y deja que la CLI siga siendo la fuente ejecutable de verdad del despliegue.
npm install -g dockup-cli
dockup skill install
El primer comando instala la CLI. El segundo instala el skill de Dockup correspondiente para Claude Code y Codex. Empieza gratis en app.dockup.ai.
Preguntas frecuentes
¿Son lo mismo los agent skills y MCP?
No. Un skill proporciona principalmente instrucciones y conocimiento operativo. MCP proporciona un protocolo para exponer herramientas, recursos y prompts mediante una conexión cliente-servidor.
¿Un archivo SKILL.md ejecuta comandos por sí mismo?
No. Indica al agente cómo utilizar capacidades subyacentes, como una CLI, archivos, APIs o herramientas MCP. La interfaz ejecutable realiza la acción.
¿Cuándo es mejor un skill que MCP?
Un skill suele ser la opción más sencilla cuando una CLI local madura ya proporciona operaciones seguras y legibles por máquinas, y lo que falta es orientación sobre el workflow.
¿Puede un agente utilizar un skill y MCP conjuntamente?
Sí. Un skill puede describir un workflow de varios pasos y su política, mientras que un servidor MCP expone las herramientas y los recursos tipados que utiliza ese workflow.
¿Por qué Dockup incluye su skill en el paquete de la CLI?
Empaquetarlos juntos permite que dockup update actualice el ejecutable y sus instrucciones de una sola vez, reduciendo el riesgo de que el skill describa una versión de comandos diferente.