Claude Skills vs MCP: cuál usar y por qué un SaaS publica los dos

Claude Skills vs MCP es una elección entre enseñar y dar acceso. Usa una Skill cuando el agente ya puede llegar a todo lo que necesita y sigue haciendo mal el trabajo: la Skill guarda tu procedimiento, tu formato de salida y cualquier script que deba correr igual cada vez. Usa un servidor MCP cuando el agente necesita datos en vivo o tiene que actuar en un sistema al que de otro modo no llega. Usa los dos cuando el trabajo es un procedimiento sobre un sistema en vivo, que es el caso habitual de un producto SaaS. Si dudas, escribe primero la Skill: es un archivo markdown, y te mostrará qué llamadas necesita el procedimiento que el agente no puede hacer.

Todo lo que sigue se comprobó el 7 de octubre de 2026 con la documentación de Anthropic y la especificación de MCP (revisión 2026-07-28), y las cifras de tokens son mediciones propias sobre nuestro propio servidor y nuestras skills.

¿Qué es exactamente una Claude Skill?

Una Skill es un directorio con un archivo obligatorio. SKILL.md empieza con un frontmatter YAML que lleva dos campos obligatorios: name (hasta 64 caracteres, letras minúsculas, números y guiones, y no puede contener "anthropic" ni "claude") y description (hasta 1.024 caracteres). El cuerpo en markdown que va debajo es el procedimiento. Al lado puedes poner más archivos markdown, datos de referencia y scripts.

El mecanismo que abarata las Skills es la revelación progresiva, y la documentación de Agent Skills de Anthropic la describe en tres niveles. Al arrancar, solo el nombre y la descripción de cada Skill instalada entran en el prompt de sistema, unos 100 tokens cada una. Cuando una petición coincide con una descripción, Claude lee el cuerpo de SKILL.md desde el sistema de archivos; la recomendación de Anthropic es mantenerlo por debajo de 5.000 tokens. Todo lo demás de la carpeta solo se carga cuando el cuerpo apunta a ello, y los scripts corren por bash, así que al contexto entra solo su salida, nunca su código.

De ahí salen dos consecuencias. La descripción es un clasificador: Claude decide si abre la Skill comparando la petición con ese único párrafo, así que tiene que decir qué hace la Skill y cuándo usarla, con las palabras que escribiría un usuario. Y una Skill puede llevar mucho material sin coste, porque un archivo de referencia que esta vez nadie necesita nunca se lee.

Las Skills llegaron a Claude el 16 de octubre de 2025 y se convirtieron en estándar abierto el 18 de diciembre de 2025. La lista de clientes de agentskills.io (leída el 7 de octubre de 2026) incluye Claude Code, Cursor, GitHub Copilot, VS Code, Gemini CLI, OpenAI Codex, Goose y OpenCode, así que "Claude Skills" es ya sobre todo un nombre que indica de dónde salió el formato.

¿Qué es exactamente un servidor MCP?

El Model Context Protocol conecta una aplicación de IA (el host, como Claude Code o VS Code) con servidores que aportan contexto. El host abre una conexión cliente por servidor, y los dos hablan JSON-RPC 2.0. Un servidor puede ofrecer tres tipos de cosas: herramientas que llama el modelo, recursos que lee y prompts que el usuario invoca como plantillas. El cliente los descubre con tools/list y sus equivalentes, y el host pasa las definiciones de herramientas al modelo, que luego decide cuándo llamarlas.

Hay dos transportes estándar. Stdio corre el servidor como un proceso local en la máquina del usuario y encaja con las herramientas de desarrollo. Streamable HTTP lo corre en remoto, así que un despliegue sirve a muchos clientes; es el transporte que usa un producto SaaS. El antiguo transporte SSE está obsoleto, y Claude Code lo marca así en su propia documentación de configuración.

La especificación sigue cambiando, y quien construya un servidor hoy debería leer la revisión 2026-07-28 y no un tutorial del año pasado. Hace el protocolo sin estado: cada petición lleva su versión de protocolo y sus capacidades, y los servidores anuncian lo que soportan con una petición obligatoria server/discover. Declara obsoleto el sampling (servidores que piden completados al modelo del cliente). Y en la especificación de autorización declara obsoleto el registro dinámico de clientes en favor de los OAuth Client ID Metadata Documents, y mantiene el DCR solo por compatibilidad.

¿Dónde se ejecuta realmente cada uno?

Dónde corre una pieza decide a qué puede llegar, así que comprueba esto primero.

Una Skill corre donde corra el agente, con exactamente el acceso que tenga ese entorno. La documentación de Anthropic enumera las diferencias por superficie. En la API de Claude, las Skills corren dentro del contenedor de ejecución de código sin acceso a la red y sin instalación de paquetes en tiempo de ejecución. En claude.ai, el acceso a la red va de completo a nulo según los ajustes del usuario y del administrador. En Claude Code, los scripts de una Skill tienen el mismo acceso a la red que cualquier otro programa de tu ordenador.

Un servidor MCP corre en su propio proceso. Un servidor remoto corre en la infraestructura del proveedor, con el acceso propio del proveedor a su base de datos y sus APIs; el agente envía una petición y recibe un resultado. Un servidor stdio corre en la máquina del usuario con las credenciales del usuario tomadas del entorno.

Así que la pregunta "¿puede una Skill hacer lo que hace mi servidor MCP?" tiene una respuesta que depende de la superficie. En Claude Code, funciona una Skill cuyo script llama a tu API con una clave del entorno. En la API de Claude, esa misma Skill no puede llegar a tu API en absoluto. Para un producto que usan personas que no controlas, desde clientes que no eliges, el servidor MCP es la parte que funciona en cualquier cliente compatible con MCP.

También cambia cómo se comparte. Las Skills propias no se sincronizan entre superficies de Claude: lo que se sube a claude.ai es personal de ese usuario, lo que se sube por la API se comparte con el espacio de trabajo, y Claude Code lee ~/.claude/skills/ o el .claude/skills/ del proyecto. Un servidor MCP remoto es una URL a la que se conectan todos los clientes.

¿Qué gasta más contexto, una Skill o un servidor MCP?

Medimos los dos sobre nuestros propios artefactos con el endpoint de conteo de tokens de Anthropic el 7 de octubre de 2026 (modelo claude-sonnet-4-5):

• El servidor MCP de visibilidad de INITE expone tres herramientas (analyze_site, get_analysis, match_tools). Enviar sus definiciones añade 998 tokens de entrada a una petición. Una herramienta sola añade 660, porque la API inserta un preámbulo fijo de uso de herramientas en cuanto hay alguna; la segunda y la tercera añadieron 103 y 235.
• Nuestra skill publicada que maneja el mismo servidor, inite-ai-visibility-audit, cuesta 69 tokens de metadatos y 636 tokens por el archivo SKILL.md completo, frontmatter incluido, una vez cargado.
• Dos de nuestras skills internas de redacción cuestan 89 y 127 tokens de metadatos. Sus cuerpos completos ocupan 2.399 y 6.769 tokens, y el segundo supera la recomendación de 5.000 tokens de Anthropic, lo que es un motivo para pasar parte a un archivo de referencia.

A escala, la diferencia es grande. La documentación de tool search de Anthropic da unos 55.000 tokens de definiciones para una configuración de cinco servidores (GitHub, Slack, Sentry, Grafana y Splunk) y dice que la selección de herramientas de Claude empeora a partir de 30 a 50 herramientas disponibles. Su solución es diferir la carga y dejar que Claude busque las tres a cinco herramientas que necesita una petición, lo que según Anthropic reduce los tokens de definiciones en más de un 85 por ciento. La documentación de MCP de Claude Code dice que tool search está activado por defecto desde la versión 2.1.232.

Los resultados también gastan contexto. La misma página de Claude Code dice que avisa cuando un solo resultado de herramienta MCP pasa de 10.000 tokens y lo limita a 25.000 por defecto. El script de una Skill devuelve solo su salida, así que un script que imprime "validation passed" cuesta unos pocos tokens.

¿Puede una Skill sustituir a un servidor MCP, o al revés?

Una Skill puede sustituir a un servidor MCP solo donde el entorno del agente ya tiene el acceso, lo que en la práctica significa Claude Code en una máquina que tiene las credenciales. El equipo de LlamaIndex, escribiendo sobre su propio constructor de agentes, planteó el compromiso como ejecución predecible con MCP frente a instrucciones interpretadas con Skills: una llamada a una herramienta funciona o falla, mientras que una Skill se puede malinterpretar.

Un servidor MCP no puede sustituir a una Skill. Puede describir cada herramienta, y una buena descripción dice cuándo llamarla, pero no tiene sitio para "llama a esto, luego a aquello, comprueba el resultado y da la respuesta como lista de tareas para un responsable de marketing". La propia regla de Anthropic, de su artículo de diciembre de 2025 sobre Skills y MCP, es la más limpia: "If you're explaining how to do something, that's a skill. If you need Claude to access something, that's MCP." (Si estás explicando cómo hacer algo, es una skill. Si necesitas que Claude acceda a algo, es MCP.) El mismo artículo señala que una Skill puede coordinar varios servidores MCP y que un servidor puede servir a muchas Skills.

¿Cuándo conviene usar los dos?

Siempre que el trabajo tenga pasos y al menos uno toque un sistema en vivo. Un informe semanal es un ejemplo: MCP conecta la base de datos y el almacén de documentos, y la Skill guarda las reglas de normalización y la plantilla. Otro es cualquier cosa con una secuencia fija, como "lanza la ejecución, espera, lee el resultado y luego explícaselo a un dueño no técnico", donde el servidor solo dejaría al agente adivinando el orden.

Nuestro propio par funciona así. El servidor MCP inicia una auditoría y devuelve un id de ejecución; una segunda herramienta lee el resultado alrededor de un minuto después. La Skill le dice al agente cuándo una auditoría es la respuesta correcta, que las dos llamadas van en ese orden y cómo explicar la puntuación a quien la pidió. Un agente que solo tiene la lista de herramientas debe deducir el orden de dos descripciones; un agente que solo tiene la Skill leería sobre una auditoría que no tiene forma de iniciar.

¿Qué debería publicar un proveedor SaaS para ser AI-native?

Para un producto SaaS, la comparación de arriba se resuelve en una lista corta. La mayoría de los agentes llaman a herramientas en lugar de abrir tu panel. Ese cambio es lo que señala la expresión AI-native, y los dos estándares son lo que lo hace concreto.

El plan de construcción, semana a semana, está en el plan de un servidor MCP en 90 días. La parte del navegador del mismo problema, hacer tu interfaz legible para los agentes que usan el ordenador, está en SaaS preparado para agentes de navegador. Si tu sitio es legible para los asistentes que, para empezar, recomendarían tu producto es lo que mide la revisión gratuita de visibilidad en IA.

¿Qué suele salir mal?

• Descripciones de herramientas vagas. El modelo nunca elige la herramienta. Escribe descripciones con verbos, entradas y una frase sobre cuándo usarla.
• Salidas sin límite. Una llamada llena el contexto. Pon un tope, pagina o devuelve un resumen con un enlace.
• Demasiadas herramientas. Pasadas las 30 a 50 herramientas, la selección empeora. Fusiona las casi duplicadas y agrupa el resto con prefijos (billing_, reports_) para que tool search pueda encontrar un grupo.
• Claves de API en lugar de OAuth. Cada instalación necesita un viaje manual a un archivo de configuración.
• Un servidor sin Skill. Las llamadas se hacen en el orden equivocado y la respuesta vuelve con la forma equivocada.
• Una Skill que da por hecho que hay red. Funciona en Claude Code y falla en la API.
• Una descripción de Skill genérica. La Skill nunca se abre, porque nada en la petición coincide con ella.
• Instalar Skills de desconocidos. La documentación de Anthropic dice que hay que tratar una Skill como software instalado: una maliciosa puede hacer que el agente ejecute código o envíe datos fuera. Revisa cada archivo antes de usarla. Anthropic también señala que las Agent Skills no están cubiertas por los acuerdos de retención cero de datos.

Para la parte de gobierno, quién aprueba qué acciones puede hacer un agente sobre tus datos, mira la persona en el circuito para agentes de IA; para el patrón de plataforma detrás de publicar un servidor por producto, mira un motor, muchas pieles.

¿Cómo se elige?

Haz dos preguntas en orden. Primera: ¿necesita el agente algo a lo que no llega desde donde corre, como datos en vivo, una acción en otro producto o cualquier cosa tras un inicio de sesión? Si la respuesta es sí, necesitas un servidor MCP, y en la API de Claude o en clientes que no controlas, una Skill no puede ocupar su lugar. Segunda: ¿tiene el trabajo un orden, un formato o una regla que el agente sigue haciendo mal? Si la respuesta es sí, necesitas una Skill. Dos síes significan los dos.