MCP, Skills, Tools y Subagents: qué los diferencia y cómo cambia el stack de agentes IA en 2026

Conclusión primero: Tools, MCP, Skills y Subagents no son cuatro nombres de producto intercambiables — son cuatro capas distintas en la pila de agentes de 2026. Tools son los contratos invocables que ve el modelo (nombre + JSON Schema). MCP es el protocolo de descubrimiento e invocación entre un Host y procesos de herramientas externos. Skills son playbooks procedimentales bajo demanda (cómo hacer el trabajo). Subagents son agentes delegados con su propio contexto. Mezclarlos en una sola palabra de moda implica depurar la capa equivocada.

Escrito a fecha de 11 de septiembre de 2026. Ya cubrimos qué es MCP, el flujo de datos JSON del Agent y JSON Schema como contrato. Este artículo solo responde: qué posee cada capa, cómo se apilan y hacia dónde converge la pila de 2026.

Cuatro capas de un vistazo

Cuando alguien dice «añadir una herramienta al agente», a menudo significa cuatro cosas distintas. Sitúa la frase en esta tabla:

En una frase: Tools son «qué se puede llamar»; MCP es «de dónde vienen las herramientas»; Skills son «cómo se hace este trabajo»; Subagents son «quién lo hace, en qué contexto». JSON Schema atraviesa Tools y MCP; Skills y Subagents gobiernan sobre todo prompts, política y límites de sesión.

Tools: el contrato de llamada frente al modelo

Un Tool (o Function) es la unidad invocable más pequeña que ve el modelo. Los nombres de proveedor difieren — OpenAI Tools / Function Calling, Anthropic Tool Use, Gemini Function Declarations — pero la forma es la misma: declaras herramientas; el modelo devuelve tool_calls estructurados; el Host los ejecuta y escribe los resultados de vuelta en el chat.

Una definición de herramienta suele verse así:

{
  "type": "function",
  "function": {
    "name": "validate_json",
    "description": "Validate JSON text and return parse errors.",
    "parameters": {
      "type": "object",
      "properties": {
        "text": { "type": "string" }
      },
      "required": ["text"],
      "additionalProperties": false
    }
  }
}

Lo que realmente restringe el comportamiento es JSON Schema: nombres de campos, tipos, required, additionalProperties. Los modelos pueden cambiar; el Schema no debería derivar con ellos. Consulta por qué Tool Calling depende de JSON Schema para la disciplina de validación. Aquí el punto es simple: un blurb de herramienta en lenguaje natural sin Schema ya no es un contrato de producción en 2026.

El límite de la capa Tools es nítido: no decide si la implementación corre en el mismo proceso o en remoto, y no decide cómo se parte el trabajo de varios pasos. Eso pertenece a MCP y a Skills / Subagents.

MCP: el enchufe de herramientas entre procesos

MCP (Model Context Protocol) responde cómo se descubren e invocan herramientas y contexto fuera del proceso Host. Los mensajes son JSON-RPC 2.0; los métodos habituales incluyen tools/list, tools/call, más Resources / Prompts. Un MCP Client dentro del Host (Cursor, VS Code, Claude Desktop, …) se conecta a un MCP Server y traduce las herramientas expuestas al array Tools que entiende el modelo.

La pila correcta es:

1. El MCP Server describe cada tool con inputSchema (sigue siendo JSON Schema);
2. El Host llama a tools/list y mapea el resultado a declaraciones Tool del modelo;
3. El modelo emite tool_calls;
4. El Host emite tools/call al Server y escribe result de vuelta en el diálogo.

Llamar a MCP «otro Function Calling» es el malentendido más común de 2025–2026. Function Calling vive en el límite de la API del modelo; MCP vive en el límite Host ↔ Server. La especificación actual es 2026-07-28: sin handshake de sesión; las peticiones llevan _meta. Detalles: guía MCP y guía de migración.

Cuándo no necesitas MCP: un solo proceso, herramientas cableadas en el Host, sin reutilización entre apps — Tool Calling solo basta. Cuándo sí: reutilizar el mismo Server entre IDEs / escritorios, aislamiento de procesos, descubrimiento dinámico de herramientas.

Skills: playbooks reutilizables de cómo hacerlo

Un Skill no es otra herramienta — es conocimiento procedimental que el agente puede cargar bajo demanda: cuándo activarlo, qué pasos seguir, qué comprobar, qué herramientas pueden usarse. En forma de ingeniería suele ser un SKILL.md del repo (o un paquete de reglas equivalente): título, condiciones de disparo, lista de comprobación, prohibiciones, rutas de scripts relacionados.

Frente a Tools / MCP:

En 2026, los agentes de IDE tratan Skills como ciudadanos de primera clase: las tareas cortas usan capacidades integradas; los flujos largos, las normas de equipo y los playbooks de ops viven en Skills para no pegar el manual entero en el system prompt cada vez. Un Skill puede dirigir qué Tools llamar y imponer puertas como «validar JSON antes de enviar» — pero normalmente no es un método JSON-RPC.

Una confusión habitual: un script de shell empaquetado etiquetado a la vez como Skill y Tool. Regla práctica — si el modelo lo llama una vez vía Schema y obtiene un resultado estructurado, es un Tool; si un documento dice al agente «sigue estos cinco pasos, llama herramientas cuando haga falta», es un Skill.

Subagents: delegación con contexto aislado

Un Subagent es una sesión hija a la que el padre delega: suele tener su propia ventana de contexto, un system prompt más estrecho, una allowlist de herramientas más estricta y un resumen devuelto al padre. No añade «una función más»; combate la contaminación de contexto y permite exploración en paralelo.

Usos típicos:

• Recuperación aislada — el hijo escarba en el repo o los logs; el padre solo conserva la conclusión.
• Trabajo en paralelo — cambios de frontend, tests y traducción de textos corren sin pelearse por un solo contexto.
• Roles estrechos — revisión de seguridad, exploración de código, diagnóstico de CI, cada uno con su prompt y herramientas.

En la práctica, un Subagent a menudo se expone al padre como un Tool especial (p. ej. Task / spawn_agent): los argumentos son la descripción y el tipo de tarea; el retorno es la respuesta final del hijo. Eso no significa Subagent = Tool. El Tool es la superficie de llamada; el Subagent es otro bucle de razonamiento con estado.

Frente a Skills: un Skill dice «cómo»; un Subagent decide «abrir otra sesión para hacerlo». Un Skill puede exigir «el triage complejo debe lanzar el Subagent de CI»; ese Subagent carga entonces sus propios Skills y Tools.

Cómo se apilan las cuatro capas

Una tarea real a menudo usa las cuatro. Ejemplo: «escribir un post del blog y desplegar» (ilustrativo, no el protocolo privado de este sitio):

1. El padre carga un Skill — «lista de comprobación de publicación del blog»: cuerpo, locales, sitemap, IndexNow.
2. El padre llama a un Subagent para explorar plantillas históricas de artículos y que decenas de HTML no entren en el contexto principal.
3. La sesión principal edita el frontend vía Tools (leer/escribir archivos, shell); si las herramientas viven fuera de proceso, el descubrimiento y las llamadas van por MCP.
4. Donde aparezcan parámetros estructurados, JSON Schema sigue fijando los campos — sobre todo para lo que sale de la máquina.

Flujo de datos en una línea:

User → Host / parent agent
      → Skills (pick the workflow)
      → Subagents (optional delegation)
      → Tool declarations (for the model)
      → optional MCP Client ↔ MCP Server
      → results written back into the dialogue

Chuleta de depuración: el modelo llama a la herramienta equivocada → Tools / Schema; el proceso de herramienta no conecta → MCP; se saltan pasos una y otra vez → Skill; el contexto explota o se contamina → Subagent.

Qué está cambiando en la pila de agentes de 2026

Comparado con el «meter funciones en el prompt» de 2024, 2026 se comprime en cinco cambios:

Otro hilo es la fusión de salidas estructuradas con los argumentos de herramientas: el JSON de negocio, los argumentos de herramientas y el inputSchema de MCP comparten la misma disciplina de Schema. Consulta qué es la salida estructurada y la comparación OpenAI vs Gemini.

En el lado de producto, los agentes de IDE ya no son solo «chat + autocompletado»: la pila por defecto incluye tool calling, conectores MCP, un directorio de Skills y subagentes generables. Para quien construye eso significa que entregas más que una API — herramientas descubribles (MCP/Tools) + flujos seguibles (Skills) + roles que puedes delegar cuando hace falta (Subagents).

Qué elegir y escribir ahora

• Escribe el Schema antes de exponer la herramienta. Pon additionalProperties: false, completa required; valida argumentos de ejemplo en el navegador con las herramientas de este sitio.
• Envuelve un MCP Server solo cuando las herramientas deban reutilizarse entre apps. Un script único embebido en un Host no necesita MCP.
• Codifica los flujos repetidos del equipo como Skills. Publicar, migrar, triage, revisión de seguridad — si los pasos son estables, deja de depender de «acordarse de recordárselo al modelo».
• Parte un Subagent cuando el contexto se alarga. Prefiere delegar trabajo exploratorio, de solo lectura y de alto ruido; deja decisiones y parches finales en el padre.
• No sustituyas Schema con un Skill, ni MCP con un Subagent. Proceso ≠ contrato ≠ transporte. Mezclarlos produce «el doc dice validar» mientras en producción nunca se ejecuta la comprobación.

Para comprobaciones JSON locales, guarda inputSchema, muestras de argumentos del modelo y muestras de resultado de MCP tools/call, y usa el validador JSON y el JSON Diff. Nada sale del navegador — el mismo instinto de privacidad que prioriza el dispositivo.

FAQ

Resumen

Tools definen qué puede llamar el modelo; MCP define cómo se descubren e invocan las herramientas desde procesos externos; Skills definen cómo se hace el trabajo según el manual; Subagents definen cómo se aísla y se delega el contexto. La pila de agentes de 2026 está convergiendo desde «una caja de chat + funciones ad hoc» hacia estas cuatro capas más un cinturón de contrato JSON Schema.

Haz crecer la pila de dentro hacia fuera. Acerta primero Schema y Tools; luego añade MCP, Skills o Subagents bajo la presión de reutilización, proceso o contexto. Valida muestras en local antes de publicar — los modelos pueden cambiar; los nombres de campo y required no deberían.