MCP

¿Han muerto los MCP por culpa de Skills?

Autorangel cruz
Actualizado
Publicado
Lectura11 min de lectura
¿Han muerto los MCP por culpa de Skills?

Los MCP no han muerto: siguen siendo el estándar para darle a un agente acceso a sistemas externos desde cualquier cliente. La regla práctica es corta: si quieres enseñarle al agente cómo hacer algo, usa Skills; si quieres darle acceso a algo, usa MCP.

En octubre de 2025, Anthropic lanzó Agent Skills. En horas, los feeds se llenaron de un mismo titular: los MCP han muerto. Newsletters, hilos de X y hasta posts de ingenieros que meses antes evangelizaban el protocolo empezaron a escribir obituarios.

Lo que murió fue un caso de uso específico, el de usar MCP para cosas para las que nunca fue diseñado, y Skills llegó a ocupar ese espacio con una solución más simple. Si confundes las dos cosas vas a tomar decisiones arquitectónicas equivocadas.

Qué pasó: el momento en que todos declararon a los MCP muertos

MCP (Model Context Protocol) lo publicó Anthropic en noviembre de 2024 como un estándar abierto para conectar modelos de lenguaje a herramientas externas. La promesa era clara: un protocolo único que cualquier modelo podía implementar para hablar con cualquier herramienta.

Once meses después, Anthropic lanzó Skills. La mecánica es completamente diferente: en lugar de un protocolo de comunicación, Skills son archivos Markdown con instrucciones en lenguaje natural. Describes cómo debe comportarse el agente en un dominio específico, y el modelo lo sigue. Sin servidores, sin transports, sin JSON-RPC.

El timing fue lo que desencadenó el debate. Porque si MCP requería horas de configuración para conectar una API y Skills resolvía casos similares en minutos con un archivo de texto, la pregunta natural era: ¿para qué sirve MCP ahora?

Lo que la mayoría omitió en esa discusión es que Skills hace en 5 minutos lo que MCP hace en 50.000 tokens. Son dos herramientas con propósitos distintos.

El problema real de MCP que nadie quería admitir

El protocolo tiene un problema de costos de contexto que estaba ahí desde el principio pero que pocos discutían abiertamente. Según Anthropic, el MCP de GitHub ocupa unos 26.000 tokens con las definiciones de sus 35 herramientas, y una configuración de cinco servidores (GitHub, Slack, Sentry, Grafana y Splunk) llega a unos 55.000 antes de que empiece la conversación. Eso es contexto que el modelo necesita procesar antes de hacer nada útil.

Anthropic publicó cómo reducir los costos de MCP un 98,7% con ejecución de código (de 150.000 a 2.000 tokens en su ejemplo), y parte de la comunidad lo leyó como una admisión de culpa: si necesitas reducir el costo un 98,7%, algo estaba muy mal. En cierto modo tenían razón, aunque la solución es elegante: que el agente escriba código contra las herramientas y cargue solo las definiciones que necesita, la misma idea que Cloudflare había bautizado como "Code Mode".

Los benchmarks tampoco ayudaron. En las pruebas internas de Anthropic sobre evaluaciones MCP con bibliotecas grandes de herramientas, Opus 4 acertaba un 49% sin su Tool Search Tool (que carga las definiciones bajo demanda) y un 74% con él; Opus 4.5, un 79,5% y un 88,1%. Cuando el servidor carga decenas de herramientas y miles de tokens de schema, la capacidad del modelo para seleccionar la herramienta correcta se degrada. El protocolo no tiene un bug: al modelo le cuesta más elegir cuanto más contexto carga.

Y encima, la complejidad de implementación. MCP requiere entender y construir sobre una arquitectura de hosts, clients, servers y transports. Skills es markdown. Para muchos equipos, la relación esfuerzo/resultado no cerraba.

Dónde Skills gana claramente

  • Workflows procedurales y conocimiento de dominio: si quieres enseñarle al agente cómo hace las cosas tu equipo (convenciones de código, proceso de code review, estructura de tickets), Skills es la herramienta correcta, porque ahí no hay conectividad externa, solo instrucciones.
  • Automatizaciones internas que no necesitan actualización dinámica: si el proceso no cambia frecuentemente, no necesitas un servidor que lo descubra dinámicamente.
  • Reemplazar MCPs que eran solo wrappers de CLIs o APIs simples: si tu servidor MCP básicamente ejecutaba git status o llamaba a un endpoint REST con parámetros fijos, Skills puede reemplazarlo con menos complejidad.
  • Costo de contexto bajo: solo la descripción del Skill se carga en el contexto inicial (unos 100 tokens). Las instrucciones completas se activan solo cuando el agente detecta que ese Skill es relevante.
  • Distribución trivial: una skill es una carpeta con un archivo markdown, así que compartirla es compartir un repo. Con npx skills instalas las de cualquier repo de GitHub con un comando, mientras que publicar un MCP implica empaquetar, versionar y que el usuario lo registre.

Simon Willison fue de los más entusiastas: tituló su análisis "Claude Skills are awesome, maybe a bigger deal than MCP". Su argumento es la simplicidad: una skill es Markdown con un poco de YAML y scripts opcionales, mientras que MCP es una especificación entera, y contó que casi todo lo que haría con un MCP lo resuelve con una CLI desde que trabaja con agentes de código.

Dónde MCP sigue ganando

Aquí es donde la narrativa "MCP is dead" falla más. Hay casos de uso donde MCP no tiene sustituto razonable:

  • Interoperabilidad multiplataforma: MCP funciona en Claude, ChatGPT, Cursor, Gemini, VS Code Copilot y decenas de herramientas más. Skills ya no es exclusivo de Claude (Cursor, Codex, Gemini CLI o GitHub Copilot lo soportan), pero solo cubre instrucciones: para que un agente acceda a un sistema externo desde cualquier cliente, MCP sigue siendo el estándar.
  • APIs grandes con discovery dinámico: el "Code Mode" de Cloudflare, dos herramientas (search(), que escribe código contra la especificación OpenAPI para encontrar los endpoints, y execute(), que escribe código que llama a la API) que dan acceso a una API entera con unos 1.000 tokens de contexto, sigue siendo MCP. Skills no puede hacer eso.
  • Permisos y seguridad a nivel de protocolo: MCP permite restricciones nativas como acceso de solo lectura a una base de datos o alcance limitado por usuario. Con Skills no hay ese nivel de control estructural.
  • Actualización automática: un servidor MCP refleja los cambios en una API automáticamente porque los descubre en tiempo de ejecución. Un Skill con instrucciones hard-codeadas necesita mantenimiento manual cuando cambia algo externo.
  • Adopción del ecosistema: al donarlo en diciembre de 2025, Anthropic contaba más de 97 millones de descargas mensuales de los SDK de Python y TypeScript y más de 10.000 servidores públicos activos. El protocolo pasó a la Agentic AI Foundation, un fondo de la Linux Foundation que cofundaron Anthropic, Block y OpenAI.

La postura oficial de Anthropic: complementarios, no competidores

El propio blog de Anthropic sobre Skills es explícito: "We'll also explore how Skills can complement Model Context Protocol (MCP) servers by teaching agents more complex workflows that involve external tools and software." Habla de complementar, no de reemplazar.

El 18 de diciembre de 2025, Skills se convirtió en estándar abierto, igual que hicieron con MCP. Anthropic publicó la especificación y la dejó libre para que otros la adopten. Lo leo como la intención de Anthropic de que las dos capas del stack, MCP y Skills, sean abiertas.

Armin Ronacher lo describe bien en su análisis: una skill no carga definiciones de herramientas, le da al agente el manual para usar las que ya tiene. De ahí sale una analogía útil: MCP es la fontanería, Skills es el manual de instrucciones. Puedes tener el mejor manual del mundo, pero si no hay cañerías, el agua no llega. Y las cañerías sin manual terminan en un agente que no sabe qué hacer con los datos que obtuvo.

Una advertencia sobre seguridad en producción

Antes de decidir qué usar, hay algo que no se puede ignorar. El servidor Git de referencia del repositorio oficial de MCP acumuló avisos de seguridad, todos de severidad moderada: tres en diciembre de 2025 (falta de validación de rutas, inyección de argumentos que permite sobrescribir archivos y creación de repositorios en cualquier ruta) y un path traversal en febrero de 2026. El paquete mcp-remote tuvo uno más grave, el CVE-2025-6514 con CVSS 9.6: inyección de comandos del sistema operativo al conectarse a un servidor MCP no confiable. Y según el análisis de Astrix sobre más de 5.200 servidores MCP de código abierto, el 53% usa secretos estáticos de larga vida (API keys, tokens personales) en lugar de OAuth con alcance limitado.

Nada de esto es razón para no usar MCP. Sí es razón para auditarlo antes de exponerlo en producción, especialmente si el servidor tiene acceso a datos sensibles o ejecuta comandos en tu infraestructura.

Skills y MCP, comparados

Así quedan los dos en los ejes que importan:

Skills MCP
Mejor para Workflows procedurales, conocimiento de equipo APIs externas, acceso a datos, multiplataforma
Costo de contexto Muy bajo (~100 tokens iniciales) Alto (puede llegar a 50k+ tokens)
Complejidad de implementación Baja (markdown) Alta (protocolo)
Actualización automática No Sí
Compatible con otros clientes Sí (estándar abierto: Cursor, Codex, Gemini CLI...) Sí (OpenAI, Gemini, Cursor...)
Casos de uso ideales Procedimientos internos, automatización de dev Bases de datos, grandes APIs, equipos multi-modelo

¿Cuál deberías usar en tus proyectos?

  • Si tu equipo solo usa Claude: usa Skills para workflows y conocimiento de dominio. Agrega MCP solo cuando necesites discovery dinámico de herramientas o acceso a APIs que cambian.
  • Si tu equipo usa múltiples modelos o planea hacerlo: MCP sigue siendo la elección para integraciones externas, y las skills que escribas también te sirven fuera de Claude porque el formato es un estándar abierto.
  • Si tienes un servidor MCP que básicamente es un wrapper de una CLI o un endpoint REST simple: evalúa migrarlo a un Skill. La reducción de complejidad operativa probablemente valga la pena.
  • Si tienes una API grande y compleja con docenas de endpoints: el "Code Mode" de MCP (buscar y ejecutar escribiendo código contra la API) es la arquitectura correcta. No lo abandones por seguir una tendencia.

La regla práctica: si lo que quieres enseñar es cómo hacer algo, Skills. Si lo que quieres es acceso a algo, MCP.

Lo que perdió en este debate fue el patrón de usar MCP como proxy de todo, incluyendo casos donde un archivo Markdown con instrucciones hubiera sido suficiente desde el principio. Ese caso de uso sí murió, y está bien que haya muerto.

Si todavía no conoces MCP en profundidad, lee la introducción que publiqué aquí antes de decidir si lo descartas o no, o recorre la guía completa de MCP para ver de qué estamos hablando exactamente.

Preguntas frecuentes

¿Skills reemplaza completamente a MCP?

No. Son capas distintas del stack. Skills maneja procedimientos y conocimiento de dominio: le enseña al agente cómo hacer las cosas. MCP maneja conectividad con sistemas externos: le da al agente acceso a herramientas y datos. Puedes y debes usar ambos juntos.

¿Puedo usar Skills y MCP al mismo tiempo?

Sí, y es el patrón recomendado por Anthropic. MCP actúa como infraestructura de conectividad (acceso a bases de datos, APIs, herramientas externas), mientras que Skills actúa como capa de instrucciones encima: le dice al agente cómo usar esa infraestructura en el contexto específico de tu equipo o producto.

¿MCP tiene futuro si ya lo adoptó la Linux Foundation?

El paso a la Agentic AI Foundation de la Linux Foundation en diciembre de 2025, un fondo que cofundaron Anthropic, Block y OpenAI, es la señal más fuerte de que MCP llegó para quedarse. El debate "MCP is dead" probablemente envejecerá muy mal.

Fuentes

¿Tienes un proyecto en mente?

Trabajo con Laravel, WordPress, SEO técnico y servidores MCP. El primer paso es una llamada de descubrimiento, sin costo ni compromiso, donde me cuentas qué necesitas y te digo con honestidad si puedo ayudarte.

Hablemos