Cada vez hay más formas de ampliar las herramientas de programación con IA: conectar herramientas con MCP, registrar procedimientos con Skills y delegar tareas a subagentes.
El problema es que los tres se describen como formas de «ampliar las capacidades del modelo», así que resulta difícil saber cuál elegir.
En una frase: MCP es una mano, Skill es un manual y un subagente es un compañero.
Este artículo explica qué amplía cada uno, con qué criterios elegirlos y qué aspecto tiene su combinación.
Empecemos por el resumen clave.
- MCP amplía lo que el modelo puede hacer (acceso a herramientas y datos)
- Skill amplía cómo sabe trabajar el modelo (procedimientos y conocimiento del dominio)
- El subagente amplía la mano de obra (un agente de ejecución con contexto independiente)
- No compiten entre sí, sino que se complementan. Es natural que un subagente lea un Skill y use herramientas MCP
Qué amplía cada uno
Primero comparémoslos en una tabla y después veámoslos uno por uno.
| Categoría | MCP | Skill | Subagente |
|---|---|---|---|
| Objetivo de ampliación | Capacidad (herramientas·datos) | Conocimiento (procedimientos·experiencia) | Agente de ejecución |
| Forma | Proceso de protocolo·servidor | Carpeta Markdown | Sesión de contexto independiente |
| Analogía | Mano | Manual | Compañero |
MCP es el canal que permite al modelo acceder a sistemas externos. Hace posibles tareas que el modelo no puede realizar físicamente por sí solo, como consultar una base de datos, llamar a una API interna o controlar un navegador. Su característica distintiva es que existe un servidor separado donde se ejecuta el código.
Skill no proporciona una capacidad nueva; ayuda al modelo a hacer bien algo que ya puede hacer. Guarda en archivos conocimientos sobre «cómo», como formatos de notas de versión, listas de comprobación de revisiones y reglas de documentación interna. En esencia, es solo Markdown.
Un subagente es otra instancia del modelo con una ventana de contexto independiente. Puede encargarse de tareas como explorar e investigar sin contaminar el historial de conversación principal. Aunque revise una gran cantidad de archivos, al contexto principal solo regresa la conclusión.
Tres preguntas para elegir qué usar
Cuando la elección no esté clara, hazte estas tres preguntas en orden.
Primero, ¿es algo que el modelo no puede hacer físicamente ahora mismo? Si el acceso es imposible, como al consultar una base de datos interna, la respuesta es MCP. Por mucho conocimiento que añadas, no aparecerá una mano que falta.
Segundo, ¿puede hacerlo, pero tienes que explicar el método cada vez? Entonces es Skill. Cualquier prompt repetido es candidato a convertirse en un Skill.
Tercero, ¿el volumen de trabajo contamina el contexto? Si la investigación y la exploración convierten la conversación en un cajón de sastre, es hora de aislarlas en un subagente.
Dicho de otro modo: si no hay acceso, MCP; si no hay técnica, Skill; y si no hay contexto (o es insuficiente), subagente.
En la práctica, combina los tres
No son opciones mutuamente excluyentes. La automatización bien diseñada suele tener este aspecto.
Por ejemplo, en la revisión automática de código, defines un subagente revisor (quién), haces que siga el Skill de la lista de comprobación del equipo (cómo) y le permites dejar comentarios en los PR mediante un servidor MCP de GitHub (con qué capacidad).
Los roles no se solapan; pertenecen a capas distintas. Cada uno responde a una de tres preguntas: quién, cómo y con qué.
Dos elecciones equivocadas frecuentes
Cuando se ven los límites, también se ven los antipatrones.
Un error es crear un servidor MCP para algo que un Skill resolvería. Por ejemplo, aplicar convenciones de mensajes de commit es un problema de conocimiento que se resuelve con unas líneas de Markdown; crear un servidor para ello es desproporcionado. Además, los servidores implican costes de mantenimiento y de revisión de seguridad.
El otro es procesarlo todo en una única sesión principal. Si exploras directamente una base de código grande desde la sesión principal, los volcados de archivos llenan el contexto y eliminan el espacio para implementar. Lo habitual es delegar la exploración a un subagente y recibir solo la conclusión en la sesión principal.
Resumen
En resumen: si faltan capacidades, MCP; si faltan técnicas, Skill; y si faltan manos, un subagente.
Los artículos sobre MCP y Skill tratan cada tema en detalle. Usa el criterio de este artículo para decidir primero a qué capa pertenece la automatización que quieres crear.
Seguir leyendo
- [MCP·Skill #2] Guía completa de Skills para agentes de IA, desde los comandos de barra hasta los activadores automáticos
- [Contexto de IA #5] ¿Por qué usar subagentes? Principios del aislamiento de contexto de los agentes de IA y criterios de delegación
- ¿Por qué CLAUDE.md debe ser corto? Diseño del contexto de carga permanente para agentes de IA

![Imagen de portada de [MCP·Skill #3] MCP, Skill y subagentes: ¿cuál usar y cuándo?](/assets/images/posts/1bb00db5-c156-4575-854c-7218ac263b2c/1.jpg)