Sub-agente o skill o herramienta MCP, ¿cuál eliges y cuándo?

Tres formas de ampliar Claude Code, todas están en la documentación y todas suenan útiles. Sub-agente, skill, herramienta MCP. Al principio del build-out de nuestra fleet construí las tres en el orden equivocado. Primero una herramienta MCP para algo que debería haber sido una skill, luego un sub-agente para algo que pertenecía a una herramienta MCP. Dos días de migración después quedó claro que el problema de decidir es más grande que el problema de construir. Aquí tienes la guía que me habría hecho falta entonces.

1. Entender qué son realmente las tres cosas

Una skill es un archivo Markdown con frontmatter. Lo dejas en ~/.claude/skills/<name>/SKILL.md. En cada prompt Claude escanea todas las descripciones de skills y decide por su cuenta si carga alguna. Si lo hace, el cuerpo entra como contexto. Nada de código, nada de API, solo texto que le dice a Claude cómo tiene que hacer algo.

Un sub-agente también es un archivo Markdown, pero a él lo llamas explícitamente. Con una llamada de tarea, con un slash command o porque dices en el prompt "delega eso al agente revisor". Recibe su propio contexto, su propia miniconversación, y al final te devuelve un resultado.

Una herramienta MCP es código. Código de verdad, en TypeScript o Python, que corre como servidor. Claude llama a la herramienta por JSON-RPC, recibe datos estructurados y puede seguir trabajando con el resultado. Las herramientas pueden hacer consultas a bases de datos, lanzar llamadas HTTP, escribir archivos, todo lo que puede hacer el código.

Tres capas distintas. La skill es conocimiento. El sub-agente es flujo de trabajo. La herramienta MCP es capacidad. En la práctica eso se mezcla constantemente, y por eso existe el resto de este playbook.

2. Pregunta de decisión número uno, ¿necesitas datos de fuera?

Es la pregunta más importante y va primero. Si la solución tiene que leer o escribir algo externo, es una herramienta MCP. No es negociable. Las skills no pueden, y los sub-agentes tampoco directamente. Ambos solo tienen acceso a lo que sabe hacer Claude Code por sí mismo (Read, Write, Bash, WebFetch y demás).

Un ejemplo concreto de nuestra fleet. Queríamos que Claude pudiera leer nuestra base de datos Postgres para las búsquedas de memoria. El primer intento fue una skill que decía "cuando pregunten por la memoria, ejecuta un comando psql en Bash". Funcionaba, pero era frágil. Infierno de escapes de Bash, cero conocimiento del esquema, nada estructurado. Al cabo de una semana lo reconstruimos como herramienta MCP que hace SQL de verdad y devuelve resultados tipados. La skill está borrada.

Regla práctica: si la acción necesita una API, una base de datos, un servicio o una ruta del sistema de archivos que Claude no encuentra de forma fiable por su cuenta, herramienta MCP.

3. Pregunta de decisión número dos, ¿es conocimiento o flujo de trabajo?

Si no hacen falta datos externos, seguimos. Conocimiento o flujo de trabajo.

Conocimiento significa: "cuando salga el tema X, piensa también en Y y Z". Ejemplo: "cuando el usuario quiera escribir migraciones de Postgres, recuérdale hacer copias de seguridad antes y usar prisma migrate dev --create-only en lugar de aplicar directamente". Eso es una skill. Texto Markdown, se dispara por la descripción, Claude decide por su cuenta.

Flujo de trabajo significa: "ejecuta el paso 1, luego el 2, luego el 3, y al final devuélveme Y". Eso es un sub-agente. Entrada definida, salida definida, en medio una secuencia clara.

Si te preguntas qué estás a punto de construir y puedes formularlo como "cuando X, recuerda Y", es una skill. Si lo formulas como "hace esto, luego aquello, y al final sale esto", es un sub-agente. Si no puedes expresarlo con palabras en absoluto porque lo único que necesitas son datos, herramienta MCP.

4. Pregunta de decisión número tres, ¿con qué frecuencia pasa esto?

Las skills se disparan en cada prompt que encaja con el frontmatter. Eso está bien cuando lo necesitas a menudo. Mal cuando pasa dos veces al mes, porque entonces el cuerpo de la skill se queda ahí como contexto latente y cuesta tokens para nada.

Los sub-agentes solo se disparan cuando los llamas explícitamente. Eso es perfecto para "esto lo hago cada martes" o "esto lo llamo en cada PR". Escribes el nombre y se ejecuta.

Las herramientas MCP se registran en la lista de herramientas y Claude escoge lo que necesita. Escala bien hasta muchas herramientas, pero con una lista pequeña se nota poca diferencia.

Un número concreto de nuestra práctica. Una skill de "consulta de memoria" se disparaba en aproximadamente el 40 por ciento de nuestros prompts (hablamos mucho de memoria). Era demasiado, el contexto se llenaba. Migración a una herramienta MCP que solo se llama en una búsqueda explícita. Hoy son cuatro veces por hora en lugar de 40. Tokens a la mitad.

5. Pregunta de decisión número cuatro, ¿puede funcionar sin conocimiento de la estructura?

Las skills reciben texto libre y devuelven texto libre. Los sub-agentes también. En el fondo, ambos son conversacionales. Si la respuesta es "sí, lee eso, piénsalo, formula un resultado", con eso basta.

Pero si la respuesta es "lee de la tabla X el usuario con ID 42, trae sus últimos diez pedidos, súmalos y devuelve JSON", entonces está claro que es una herramienta MCP. Estructura y tipos.

Regla práctica: si quien llama (Claude u otra herramienta) necesita el resultado como JSON parseable, herramienta MCP. Si basta con un bloque de Markdown, skill o sub-agente.

6. La trampa, construir una skill que en realidad es un sub-agente

Ese fue mi primer gran error. Tenía una skill con un cuerpo de 200 líneas que describía exactamente un flujo de trabajo. "Cuando el usuario pida ideas para posts de blog, haz el paso 1, luego el paso 2, luego el paso 3". Sub-agente clásico, mal construido.

Se destapa en cuanto lo usas. Las skills se disparan automáticamente, así que el cuerpo entraba a veces también en contextos donde no pintaba nada. El rendimiento sufrió. El sub-agente lo resolvió, porque solo corre cuando se le llama explícitamente.

Síntoma de que estás haciendo esto: tu skill tiene titulares Step-1, Step-2, Step-3. Entonces es un sub-agente. Migra.

7. La trampa, construir un sub-agente que en realidad es una herramienta MCP

Ese fue el error número dos. Un sub-agente que llamaba a psql con la herramienta Bash y tenía que parsear el resultado. Funcionaba para consultas simples y fallaba con todo lo que llevara joins o comillas. Migración a una herramienta MCP con un cliente Prisma de verdad. Cuatro horas de migración y después todo funcionaba.

Síntoma de que estás haciendo esto: tu sub-agente usa muchísimo Bash en el cuerpo, muchísimo pattern matching sobre salidas de texto, y se cae con regularidad en los casos límite. Entonces el núcleo lógico pertenece a una herramienta MCP.

8. La antitrampa rara, una herramienta MCP que debería ser una skill

Es rara, pero existe. Tienes un servidor MCP con una herramienta que simplemente devuelve un texto en Markdown con instrucciones. "Tool 'review-checklist' returns: 1. Check imports, 2. Check tests, 3. Check types". Eso es una skill. Escribir código para eso es sobrecarga.

Síntoma: tu herramienta no hace ninguna llamada a API, ninguna consulta a base de datos, ninguna entrada o salida de archivos. Solo devuelve constantes o plantillas. Bórrala y créala de nuevo como skill.

9. Ejemplos de setups de fleet reales

Cuatro casos concretos de las últimas semanas, para que veas los patrones.

Caso A. "Cuando el usuario hable de precios, recuerda la trampa del modo live de Stripe." Skill. Pura regla de conocimiento, ningún flujo de trabajo, ningún dato.

Caso B. "Escríbeme una entrada de release note a partir de este PR." Sub-agente. Entrada clara (URL del PR), salida clara (bloque de Markdown), flujo de trabajo definido en medio.

Caso C. "Dime cuántas páginas vistas tuvo la Academy ayer." Herramienta MCP. Necesita una llamada a la API de Umami, necesita autenticación, devuelve un número estructurado.

Caso D. "Comprueba si esta idea encaja con nuestra estrategia." Sub-agente con herramientas MCP a las que llama. Multicapa. Sub-agente para el flujo de trabajo, herramientas MCP para el acceso a los datos (leer la memoria de estrategia, comprobar las decisiones).

10. Orden para fundadores en solitario, qué aprendes primero

Si ahora mismo solo tienes el fin de semana, este es el orden.

Primero construye skills. Lo más barato, el aprendizaje más rápido, cero código. Dos o tres skills que necesites a menudo (estilo de code review, estilo de post de blog, precaución con Postgres). Entonces entiendes cómo funcionan los disparadores y dónde están los límites.

Luego un sub-agente. Coge un flujo de trabajo que hagas cada semana. De ticket a título de PR, o de nota de voz a tareas. Media hora de construcción, utilidad inmediata.

Y solo después una herramienta MCP. Cuando choques con que necesitas datos de verdad, la pregunta se responde sola. Entonces merece la pena el esfuerzo del setup de TypeScript. Antes no.

Tres caminos, bien repartidos. Si tienes eso en la cabeza, te ahorras los días de migración que me hicieron falta a mí.

Si quieres construirlo ahora mismo, empieza con el playbook Tu primera skill propia en 30 minutos. Cuando te toque el sub-agente, mira Tu primer sub-agente en 30 minutos. Para la herramienta MCP, Tu primer servidor MCP en 90 minutos.