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.
¿Pero es cierto? ¿O es clickbait disfrazado de análisis técnico?
La respuesta honesta es que los MCP no murieron. Lo que murió fue un caso de uso específico donde MCP se usaba para cosas para las que nunca fue diseñado. Skills llegó a ocupar ese espacio con una solución más simple. Y esa distinción importa, porque 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. Eso no es un insulto a MCP; es una descripción de 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. Un servidor como el MCP de GitHub puede consumir más de 50.000 tokens solo en JSON schemas al iniciar la conexió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, 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 que propusieron (el “Code Mode” con dos herramientas: búsqueda semántica + ejecución en sandbox) es elegante.
Los benchmarks tampoco ayudaron. Claude Haiku 4.5 tiene solo un 59,8% de precisión en lookups de datos en contextos MCP grandes. Cuando el servidor carga decenas de herramientas y miles de tokens de schema, la capacidad del modelo para seleccionar la herramienta correcta se degrada. No es un bug de MCP, es física cognitiva: más contexto no siempre es mejor.
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. Eso no es conectividad externa, es instrucción contextual.
- 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 statuso 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.
La postura de Simon Willison al analizar el lanzamiento fue pragmática: Skills hace que la personalización de comportamiento sea accesible para personas que no son ingenieros. No es una amenaza existencial para MCP; es democratización de una capa diferente del stack.
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 es Claude-only. Si tu equipo usa múltiples modelos o planeas hacerlo, MCP es la única opción que no te ata a un vendor.
- APIs grandes con discovery dinámico: el “Code Mode” que describe el análisis de Codely —dos herramientas (búsqueda semántica + ejecución en sandbox) que dan acceso a APIs enormes sin cargar todo el schema— 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: 97 millones de descargas mensuales del SDK, más de 10.000 servidores activos. OpenAI adoptó MCP en marzo de 2025, Google DeepMind en abril, y la Linux Foundation lo tomó bajo su gobernanza en diciembre de 2025 junto con OpenAI y Block como co-fundadores. Eso no es el movimiento de una tecnología moribunda.
La postura oficial de Anthropic: complementarios, no competidores
El propio blog de Anthropic sobre Skills es explícito: “Skills can complement MCP servers by teaching agents more complex workflows that involve external tools and software.” No “reemplazar”. Complementar.
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. La lectura correcta de eso no es “MCP murió, ahora Skills es el estándar”. Es que Anthropic está construyendo un stack de dos capas y quiere que ambas sean abiertas.
La analogía más útil que encontré en el análisis de Armin Ronacher es esta: 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 oficial de Anthropic tuvo tres CVEs documentados en 2025, incluyendo path traversal y ejecución de código arbitrario. El paquete mcp-remote tuvo el CVE-2025-6514 con CVSS 9.6, un RCE vía flujo OAuth. Y según auditorías del ecosistema, el 53% de los servidores MCP activos usan API keys estáticas de larga vida 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.
El sistema de dos niveles que nadie esperaba
Los MCP no murieron. Encontraron su lugar correcto en el stack.
La forma más clara de verlo es comparar 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 modelos | No (Claude-only) | 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?
La decisión no es filosófica, es operativa:
- 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. No existe un equivalente de Skills para otros modelos todavía.
- 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 (búsqueda semántica + ejecución en sandbox) 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.
El verdadero perdedor en este debate no fue MCP como tecnología. 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 específico 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.
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?
La gobernanza bajo la Linux Foundation en diciembre de 2025, con OpenAI y Block como co-fundadores del proyecto, es la señal más fuerte de que MCP llegó para quedarse. Los estándares que entran a la Linux Foundation no mueren: se estandarizan. El debate “MCP is dead” probablemente envejecerá muy mal.