Claude Code Skills vs MCP servers: cuándo usar cada uno (guía práctica LatAm 2026)

Llevo un año usando Claude Code todos los días. Instalé Skills, instalé servidores MCP, y en un momento perdí la cuenta de qué hacía qué. Cuando un compañero me preguntó “¿esto lo pongo como Skill o como servidor MCP?”, di una respuesta larga, borrosa, y bastante inútil.

Este artículo es lo que le habría contestado si hubiera pensado antes. Cinco tareas reales, cinco decisiones concretas, y un criterio único que ahora uso para no tener que pensarlo de nuevo.

Si vienes de otro entorno de agentes, cámbiale el nombre a lo que uses: Skills = comandos personalizados invocables, MCP servers = adaptadores externos que exponen herramientas. Los mismos trade-offs aplican.

La diferencia que importa (una sola frase)

Skills se disparan cuando tú los llamas. MCP servers están siempre disponibles como herramientas.

Todo lo demás sale de ahí. Presupuesto de tokens, permisos, mantenimiento, distribución en equipo — cada trade-off es una consecuencia de esa diferencia.

Skills vs MCP: el eje que decide

Skills en una hoja

Una Skill es una carpeta con un archivo SKILL.md y opcionalmente scripts, plantillas y ejemplos. Se invoca con /nombre-skill. Vive en .claude/skills/ (proyecto), ~/.claude/skills/ (usuario) o dentro de un plugin.

Ejemplo mínimo:

---
name: review-pr
description: Hacer code review de un PR. Usar cuando pidan revisión de PR.
allowed-tools: Bash(gh *) Read Grep
---

## Pasos
1. `gh pr diff` para obtener el diff
2. Leer los archivos modificados
3. Verificar lógica, edge cases, seguridad
4. Publicar el resultado como comentario en el PR

Se ejecuta cuando escribes /review-pr o cuando el modelo detecta que la description coincide con la petición. En un servidor grande con 200 archivos, Skill no consume tokens hasta que se invoca.

MCP servers en una hoja

Un servidor MCP es un proceso externo (Node, Python, Go, cualquier cosa) que habla el protocolo Model Context Protocol y expone un catálogo de herramientas. Se declara en claude_desktop_config.json o el equivalente de tu cliente:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "ghp_..." }
    }
  }
}

Cuando arranca el cliente, se conecta al servidor y lee su lista de herramientas. Todas quedan disponibles en la ventana de contexto desde el momento cero. Esto es lo bueno y lo caro al mismo tiempo.

Comparación en 5 dimensiones

Dimensión	Skills	MCP servers
Momento de activación	Cuando invocas o el modelo decide	Siempre cargado
Costo de tokens	Cero hasta la invocación	Definiciones ocupan contexto siempre
Ejecución	En el proceso del cliente	Proceso externo (a veces remoto)
Lenguaje	Markdown + shell	Cualquier lenguaje con SDK MCP
Distribución en equipo	Plugin (`plugin.json`)	Config del cliente + credenciales
Auth con servicios externos	No aplica directo	Estándar (env vars, OAuth)
Estado entre invocaciones	Sin estado (idempotente)	Puede mantener estado en el proceso

Fíjate en la primera fila. Casi todos los criterios de decisión salen de ahí. Si la tarea es “cuando pase X, quiero que Y”, pensar Skill. Si es “quiero acceso permanente a la API de Z”, pensar MCP.

5 tareas reales: mi elección y por qué

Cinco tareas que resolví el mes pasado. Con la decisión y una nota corta.

1. Publicar una nota en Notion cada vez que cierro un PR

Elección: MCP server (@modelcontextprotocol/server-notion).

Necesito auth con Notion y acceso a su API en múltiples momentos, no siempre iniciados por mí. Un servidor MCP maneja el token, expone create_page, search_pages, y queda disponible cuando lo necesite. Una Skill sería un envoltorio innecesario alrededor de la misma llamada.

2. Generar el mensaje de commit siguiendo el formato interno de la empresa

Elección: Skill (.claude/skills/commit-msg/).

Es lógica pura de plantilla + reglas de estilo. Sin auth, sin API externa. Se invoca con /commit-msg. Cero tokens hasta que la llamo. Si fuera un servidor MCP, sus definiciones ocuparían contexto en cada conversación aunque nunca lo use.

3. Consultar métricas de nuestra base de datos PostgreSQL de solo lectura

Elección: MCP server (postgres readonly).

Query dinámico, resultados en tiempo real, quiero explorar sin salir del chat. Un MCP server con permisos SELECT es exactamente el caso de uso canónico. Skill no puede porque no tiene la conexión persistente.

4. Hacer que el modelo siga un checklist específico antes de decir “listo para producción”

Elección: Skill (/ship-check).

Es un procedimiento (SKILL.md con 12 pasos y verificaciones). Se invoca al final del flujo. La lógica está en el prompt y en algunos scripts locales de verificación. Un MCP server aquí es matar una mosca a cañonazos.

5. Enviar mensajes a nuestro canal de Slack de deploys

Elección: MCP server (slack-mcp con disable-model-invocation en las herramientas de escritura).

Requiere OAuth, formato de bloques, y quiero que las escrituras estén detrás de una confirmación explícita. Skill con Bash(curl *) funcionaría, pero manejar el token, el rate limit y el retry termina siendo un mini-servidor MCP mal escrito. Mejor usar el MCP real desde el principio.

El criterio único que ahora uso

Cuando dudo, hago tres preguntas en este orden:

1. ¿La tarea empieza con un evento del usuario? Si sí (“cuando yo diga X”), Skill. Si no (“cuando el modelo detecte Z” o “en cualquier momento del chat”), sigue leyendo.

2. ¿Necesitas auth persistente contra un servicio externo? Si sí, MCP server (gestiona tokens, refresh, retry). Si no, sigue.

3. ¿La lógica cabe en Markdown + un par de scripts locales? Si sí, Skill. Si necesitas un cliente HTTP con estado, retries, o rate limits complicados, MCP.

En la práctica, el 70% de mis casos cae en Skill (procedimientos, plantillas, checklists) y el 30% en MCP (integraciones con servicios externos). Antes de este criterio me pasaba lo contrario: lo hacía todo con MCP porque era la novedad brillante. Terminé con 12 servidores corriendo, mi ventana de contexto llena de definiciones que nunca usaba, y una factura de tokens que subió un 40%.

Errores comunes al elegir

Poner un procedimiento interno como MCP server solo porque el equipo dijo “queremos MCP”. Un procedimiento sin dependencias externas es una Skill. Envolver el mismo shell script en un proceso Node hablando MCP es puro overhead.

Poner un cliente de API como Skill con Bash(curl *). Funciona hasta que necesitas OAuth refresh, hasta que el rate limit te bloquea, hasta que necesitas paginación. En ese momento estás escribiendo un cliente HTTP en Bash, y eso siempre acaba mal.

No usar disable-model-invocation en Skills con efectos secundarios (deploy, delete, send-message). Si el modelo puede invocar la Skill automáticamente, un prompt malicioso puede dispararla. Con disable-model-invocation: true, solo se activa cuando tú escribes /nombre-skill.

Distribución en equipo

Aquí es donde los Plugins entran. Un Plugin agrupa Skills, Hooks y sub-agents en una carpeta y los distribuye a todo el equipo desde un repositorio Git. Las Skills quedan bajo el namespace del plugin (plugin-name:skill-name), así que no chocan con las Skills personales de cada quien.

Para MCP servers, la distribución sigue el patrón viejo: config del cliente + credenciales por miembro del equipo. No hay atajos aquí en 2026-08. Si tu equipo comparte servidores MCP, considera un catálogo interno (yaml + script de instalación) para que nadie tenga que copiar-pegar claude_desktop_config.json desde Notion.

Referencias

(inglés) Natural-Language Agent Harnesses (arXiv 2603.25723): Survey Notes and My Take — el paper de referencia clasifica Skills y servidores MCP como primitivas distintas del harness engineering
Documentación oficial: Skills, MCP

Cierre

La regla que sigo hoy: Skill por defecto, MCP cuando el trabajo lo pide. Reservar la ventana de contexto para lo que se usa en cada conversación, no para las 47 herramientas que quizá algún día uses. Si terminas con más de 5 servidores MCP activos siempre, probablemente 2 de ellos deberían haber sido Skills.

Cuando releo mi propio claude_desktop_config.json de hace 6 meses, todavía me río un poco. Tenía siete servidores MCP corriendo, seis los usaba una vez al mes, y uno estaba caído desde febrero sin que me diera cuenta. Menos es más — y ahora lo digo mientras miro con culpa la Skill de “generar excusas creativas para no salir el viernes” que sigue en mi carpeta desde el año pasado.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev