MCP vs Skills: diferencias y cuándo usar cada uno

MCP conecta un agente con herramientas y datos externos en el momento en que los necesita. Una skill le da al agente instrucciones ya empaquetadas que carga en su propio comportamiento antes de actuar. Resuelven problemas distintos, y confundirlos hace que montes infraestructura que no necesitas o que le pidas a una skill algo que no puede hacer.

Si vienes de cero con estos dos términos, esto es lo mínimo para seguir el resto del post. MCP (Model Context Protocol) es un protocolo abierto: un servidor MCP expone un conjunto de funciones (herramientas) que un agente puede llamar en tiempo real, igual que una API pero pensada para que el modelo la descubra sola. Lo explico con detalle en qué es MCP. Una skill, en cambio, es una carpeta con un archivo SKILL.md: metadatos más instrucciones en markdown que el agente lee cuando la tarea encaja con lo que esa skill describe. La defino a fondo en qué es una skill.

MCP vs Skills, lado a lado

	MCP	Skill
Qué es	Protocolo cliente-servidor que expone herramientas, datos o prompts	Carpeta con SKILL.md (instrucciones) y, opcionalmente, scripts o plantillas
Cuándo se carga	En cada llamada, en tiempo de ejecución	Metadatos siempre visibles; el contenido completo solo si la tarea la activa
Qué resuelve	Acceso a un sistema externo que cambia: base de datos, API, servicio en vivo, cola de tareas	Que el agente siga bien un procedimiento reutilizable, sin repetírselo cada vez
Coste de contexto	Una llamada de función por uso, con su resultado	Casi cero hasta que se activa; entonces mete su contenido completo en el contexto
Ejemplo típico	Un servidor que consulta el estado real de un pedido en tu base de datos	Una skill que sabe generar un informe con el formato exacto que usa tu equipo

La fila que más confusión genera es la de coste de contexto. Un servidor MCP con muchas herramientas puede llenarte la ventana de contexto con definiciones de funciones que el agente ni va a usar en esa tarea. Una skill bien diseñada hace lo contrario: solo su nombre y descripción están siempre presentes, y el resto entra únicamente cuando hace falta. Esto se llama carga progresiva.

Cuándo usar cada uno

La pregunta que de verdad importa no es “¿cuál es mejor?”. Es: ¿el agente necesita hablar con algo externo que puede cambiar, o necesita saber hacer bien algo que ya sabe cómo se hace?

Necesitas un servidor MCP cuando el agente tiene que leer o escribir en un sistema que vive fuera de la conversación: tu base de datos de producción, un CRM, un servicio de pagos, el estado actual de un ticket. Eso no se puede empaquetar como instrucción estática porque el dato cambia entre una llamada y la siguiente.

Te basta con una skill cuando lo que hace falta es que el agente siga un procedimiento con criterio: el formato exacto de tus commits o los pasos para revisar un pull request según las convenciones de tu equipo. Nada de eso requiere hablar con un sistema externo nuevo. Es conocimiento sobre cómo hacer algo, no acceso a algo.

Y aquí está el caso que casi nadie explica bien: es habitual que se combinen dentro de la misma skill. Una skill de “cerrar un sprint” puede incluir en su SKILL.md el paso “usa la herramienta MCP get_open_tickets para comprobar que no queda nada abierto antes de cerrar”. La skill aporta el criterio y la secuencia; el servidor MCP aporta el dato real en el momento en que se necesita. Una skill sin acceso a datos vivos solo puede razonar sobre lo que ya está en el contexto, y un servidor MCP sin nadie que sepa cuándo usarlo es una lista de funciones sueltas.

Si estás diseñando cómo un agente accede a herramientas y a qué patrón recurrir en cada capa, el curso de patrones agénticos cubre esta decisión con más casos que los que caben en un post.

Preguntas Frecuentes

¿Puedo usar MCP y Skills a la vez en el mismo agente?

Sí, y es el caso más común en la práctica. El agente carga las skills relevantes para la tarea y, cuando alguna de ellas necesita datos externos, llama a una herramienta MCP desde ahí mismo.

¿Una skill puede sustituir a un servidor MCP?

No si necesitas datos que cambian. Una skill puede describir el procedimiento perfecto para gestionar pedidos, pero si no tiene una herramienta MCP conectada al sistema de pedidos, no sabe cuáles están pendientes hoy. Puede simular el razonamiento, no puede inventarse el dato real.

¿Un servidor MCP puede sustituir a una skill?

Técnicamente puedes meter instrucciones largas en la descripción de una herramienta MCP, pero no es su diseño: una herramienta MCP describe una función que se ejecuta, no un procedimiento de varios pasos que el agente debe interiorizar. Para eso existen las skills.

¿Y una API REST, dónde encaja en esta comparación?

No compite con ninguna de las dos directamente. Una API REST es lo que expone tu propio backend; MCP es el protocolo que hace que un agente la descubra y la llame sin que tengas que documentártela a mano en el prompt. Si tu duda de fondo es si te conviene envolver tu API en un servidor MCP, esa decisión la cubro en MCP vs API: es un problema distinto al de elegir entre skill y MCP.

¿Cuál monto primero si estoy empezando?

Si tu agente ya tiene todos los datos que necesita en el contexto y solo falla en seguir bien un proceso, empieza por una skill: es una carpeta con un SKILL.md, no requiere infraestructura. Monta un servidor MCP cuando el bloqueo real sea que el agente no puede ver ni tocar algo que vive fuera de la conversación.