La respuesta corta
Si tu flujo con IA necesita sobre todo instrucciones y contexto que el modelo debe seguir, normalmente basta con un skill de agente reutilizable. Si necesita sobre todo hablar con un sistema externo —leer datos, escribir en él o actuar con la cuenta del usuario—, casi siempre necesitas un servidor MCP. El truco está en que ambas cosas se solapan, y ese solapamiento es donde los builders en solitario pierden más tiempo.
Esta guía te da un modelo mental de una página, un árbol de decisión simple y algunas reglas prácticas para que dejes de construir infraestructura que no necesitas.
Por qué existe esta confusión
Anthropic presentó el Model Context Protocol a finales de 2024 y, alrededor de un año después, lanzó Agent Skills. Como la misma empresa publicó ambos estándares y los dos “conectan” la IA con algo externo, muchos desarrolladores asumen que compiten. No es así. Resuelven problemas diferentes que por fuera se parecen.
Una forma de mantenerlos separados, muy usada en la comunidad:
MCP da capacidades a tu agente. Los skills enseñan flujos de trabajo. Las tools son las acciones concretas que se invocan.
Esa frase hace casi todo el trabajo. Lo que sigue es solo desglosarla.
Qué hace realmente un servidor MCP
Un servidor MCP es un programa pequeño que expone un conjunto de tools —acciones como “listar mis archivos”, “crear un issue”, “consultar la base de datos”— a través de un protocolo estandarizado. Tu host de IA (Claude Code, ChatGPT, VS Code, Goose y otros) habla ese protocolo, así que cualquier servidor MCP se conecta con cualquier host.
Por qué esto le importa a un fundador independiente:
- OAuth viene incluido. MCP trae autenticación de fábrica. El servidor puede pedir al usuario que inicie sesión con su propia cuenta en el servicio externo (GitHub, Notion, un CRM, tu cuenta en la nube) y se usan las credenciales de ese usuario. Sin el problema de “pegar una API key global”.
- Un servidor sirve en muchos hosts. Lo construyes una vez y funciona hoy en Cursor y mañana en Claude Code. La comunidad MCP lo llama “USB-C para IA”.
- Es la abstracción correcta cuando hay I/O real. Leer un archivo en almacenamiento cloud, crear un ticket, ejecutar una consulta, enviar un webhook: cualquier acción con efectos sobre otro sistema.
El inconveniente, y es real: hoy, muchos servidores MCP inyectan de forma entusiasta el esquema completo de cada tool en el contexto del modelo. Si conectas una docena de servidores, la ventana de contexto se llena de descripciones de tools que quizá nunca uses. Es el famoso problema de “MCP context bloat”. No es inherente al protocolo —es cómo se comportan hoy la mayoría de implementaciones—, pero es lo que vas a notar.
Qué hace realmente un skill de agente
Un skill de agente es, a grandes rasgos, una carpeta con instrucciones bien escritas que el modelo carga bajo demanda. El archivo del skill tiene una descripción corta en un frontmatter YAML (el bloque de metadatos al inicio del archivo) que le dice al modelo para qué sirve el skill; el resto del archivo es el playbook real: un flujo paso a paso, referencias a otros archivos que el modelo puede traer si los necesita y, a veces, pequeños scripts que el modelo puede ejecutar.
Lo ingenioso se llama progressive disclosure: por defecto, el modelo solo ve el nombre del skill y una descripción de una línea. Abre las instrucciones completas solo cuando decide que el skill es relevante. Eso mantiene la ventana de contexto limpia.
Los skills son la abstracción correcta cuando:
- El conocimiento es sobre todo procedural. “Así quiero que clasifiques un correo de soporte.” “Este es el estilo de nuestros changelogs.” “Este es el esquema de nuestra API interna.”
- Los datos viven en archivos que tú controlas. Guías de estilo, runbooks, documentación de esquemas, logs de decisiones: cualquier cosa que sea “lee esto y actúa”.
- Iteras rápido. Los skills son archivos markdown. Editas uno, vuelves a correr el agente y ves si mejoró. El ciclo de feedback es de minutos, no de semanas.
Esa es la razón por la que tantos desarrolladores los ven como algo más grande que MCP. Escribir buena documentación solía ser un trabajo ingrato. Escribir un skill que vuelve útil a tu propio agente de IA tiene recompensa inmediata.
Dónde se solapan de verdad
Aquí es donde la confusión muerde. Un skill puede incluir un script que llama a una API. Un servidor MCP puede incluir prompts y recursos que parecen instrucciones. En teoría, puedes resolver muchos de los mismos problemas con cualquiera de las dos abstracciones.
Ese solapamiento es real y ha alimentado los titulares de “MCP está muerto”. No lo está. Lo que cambió es que los skills manejan la capa de workflow mucho mejor de lo esperado, mientras MCP sigue siendo dueño de la capa de conexión.
Una forma útil de ver el límite: si tu agente necesita actuar como un usuario concreto dentro de un servicio de terceros, MCP está haciendo un trabajo que los skills no pueden hacer de forma segura. Eso incluye cualquier cosa donde importa el OAuth por usuario —un cliente que use su propia cuenta de GitHub, su propio Notion, su propio proyecto en la nube.
El árbol de decisión
Recorre estas preguntas en orden. Detente en el primer “sí”.
1. ¿El agente necesita ejecutar una acción en un sistema externo?
Esa acción puede ser de solo lectura (consultar una base de datos, listar issues, traer un documento) o de escritura (crear, actualizar, borrar, enviar). Si la respuesta es sí, casi seguro quieres un servidor MCP.
Si la respuesta es no —el trabajo es puramente “lee estos archivos y sigue estas instrucciones”—, sigue.
2. ¿El sistema externo lo usa solo un desarrollador (tú) y la historia de autenticación es simple?
Por ejemplo, un script local que lee de tu propia base de datos Postgres con una sola cadena de conexión. En ese caso, un skill que envuelve un pequeño CLI puede ser suficiente. No necesitas el protocolo MCP completo, ni el registro, ni las opciones de transporte, ni la danza de OAuth.
Si el sistema es compartido, multi-tenant o necesita las credenciales propias del usuario final —sigue.
3. ¿Querrás la misma capacidad en más de un host de IA?
Si la respuesta es “tal vez después, pero ahora no”, un skill sigue siendo suficiente. Los skills viajan bien entre Claude, ChatGPT y otros hosts que adopten el estándar. Si la respuesta es “seguro, y quiero que se sienta nativo en todas partes”, esa es una señal fuerte hacia MCP, porque toda la propuesta de valor de MCP es la interoperabilidad.
4. ¿Tendrás que compartir esto con compañeros de equipo o clientes que no son desarrolladores?
Esta es la pregunta que empuja en silencio a la mayoría de equipos hacia MCP. Si tu líder de soporte o un cliente necesita iniciar sesión con su propia cuenta en un servicio de terceros y hacer que la IA actúe en nombre de esa cuenta, OAuth y el transporte de MCP lo resuelven limpiamente. Los skills no tienen una forma nativa de hacer auth por usuario: suelen apoyarse en un token de API compartido, lo cual no funciona en escenarios multiusuario.
Si aquí respondiste “sí”, probablemente MCP sea la elección correcta aunque un skill técnicamente pudiera hacer el trabajo.
La regla de “no construyas ambas cosas”
La mayor parte del dolor que describen los builders independientes viene de construir las dos y mantenerlas en paralelo. El patrón se ve así: escribes un skill que documenta el flujo, después envuelves el mismo flujo en un servidor MCP porque quieres OAuth, después el skill y el servidor se desincronizan y nadie sabe cuál es la fuente de la verdad.
Una regla simple lo evita:
- Elige una abstracción por capacidad. Si el trabajo es “enseña al agente cómo hacer X”, es un skill. Si la capacidad es “permite que el agente actúe sobre X con las credenciales del usuario”, es un servidor MCP.
- No dupliques la misma lógica en ambos. Si te encuentras manteniendo un archivo markdown y un endpoint de servidor que dicen lo mismo, colapsa uno.
- Deja que los skills referencien tools de MCP, no que las reemplacen. Un skill puede enseñarle al agente cuándo y por qué usar un servidor MCP concreto. El skill es el playbook; el servidor MCP es la caja de herramientas. Es la arquitectura más limpia y la que recomiendan la mayoría de guías actuales.
Un escenario realista para un fundador
Imagina que llevas un SaaS con dos personas. Quieres que tu asistente de código con IA haga tres cosas:
- Traer el feedback más reciente de clientes desde tu buzón de soporte antes de redactar una release note. Es acceso de lectura a un servicio externo. Si tú y tu socio lo necesitan usando sus propios logins, MCP es la opción más limpia.
- Seguir el estilo interno para los changelogs. Es pura instrucción. Es un skill: un archivo markdown con ejemplos.
- Abrir un ticket en Linear cuando el changelog menciona un bug. Es una acción de escritura en un sistema externo, idealmente ligada a las cuentas de Linear del equipo. MCP otra vez, con el skill diciéndole al agente cuándo dispararlo.
Son dos puntos de contacto con MCP y un skill, no tres de cada cosa. La arquitectura refleja el trabajo real.
Trade-offs que conviene tener presentes
Costo de contexto. Los servidores MCP pueden inflar tu ventana de contexto si conectas demasiados a la vez. Algunos hosts ya hacen carga diferida de tools, pero no lo des por hecho. Los skills solo consumen contexto cuando se disparan, lo cual es más amable por defecto.
Mantenimiento. Un servidor MCP es un servicio. Tiene historia de despliegue, de versionado y de autenticación. Un skill es una carpeta de markdown. Los skills son muchísimo más baratos de mantener —y de reescribir cuando cambia el flujo subyacente.
Descubrimiento. El registro de MCP ofrece un lugar centralizado para encontrar servidores que其他人 ya construyeron. En skills, el descubrimiento todavía está fragmentado: los encuentras sobre todo dentro de las apps que los soportan o en repos de proyectos.
Soporte de vendors. MCP tiene un apoyo amplio en la industria: OpenAI, Google, Microsoft, AWS y otros ya han anunciado soporte. Los skills son más nuevos y la huella de soporte es más estrecha, aunque está creciendo. Si tu stack atraviesa varios vendors, tenlo en cuenta.
Calidad de las descripciones de las tools. Un problema conocido de MCP hoy es que las descripciones de las tools en muchos servidores públicos son vagas, redundantes o les faltan campos clave. Las malas descripciones llevan al modelo a elegir la tool equivocada o a pasar argumentos malos. Es un punto de fricción real y una de las razones por las que los skills se sienten más predecibles para muchos flujos.
Preguntas frecuentes
¿Puede un skill llamar a un servidor MCP?
Sí. Un patrón habitual es escribir un skill que le dice al modelo qué servidor MCP usar y en qué situación. El skill aporta el criterio; el servidor MCP aporta la acción.
¿Necesito MCP si solo uso un host de IA?
No necesariamente. Si tienes claro que te quedarás dentro de una sola herramienta y tu flujo es sobre todo instrucciones, puede que los skills sean todo lo que necesitas. El argumento más fuerte a favor de MCP es la interoperabilidad y la autenticación por usuario.
¿MCP va a desaparecer?
Ninguna lectura seria del ecosistema actual apoya eso. Los skills complementan a MCP en lugar de reemplazarlo. Si acaso, el soporte de MCP se ha ampliado entre los vendors grandes desde que aparecieron los skills.
¿Por dónde empiezo sin sobre-construir?
Empieza con un skill. Si el flujo necesita acciones reales en un sistema externo bajo cuentas reales de usuario, gradúa esa capacidad a un servidor y deja el skill como el playbook que decide cuándo llamarlo.
Una checklist simple antes de construir
- Escribe el trabajo real en una frase.
- Marca si es “instruir al modelo” o “actuar sobre un sistema externo”.
- Marca si necesita auth por usuario.
- Marca si más de un host o miembro del equipo lo necesita.
- Elige una abstracción según las respuestas.
- Resiste la tentación de construir también la otra “por si acaso”.
Ese es todo el marco. El costo de acertar aquí no es teórico: es la diferencia entre una tarde editando markdown y un sprint levantando un servicio que no necesitabas.
Fuentes
- Agent skills vs Model Context Protocol — How do you choose? (ravichaganti.com)
- Tools, Skills, and MCP — When to Use Which Without the Headache (dailyaistudio.substack.com)
- MCP servers vs. skills: Choosing the right context for your AI (Red Hat Developer)
- MCP is dead, or MCP vs Skills — revisited (Alon Nisser, Medium)
- Discusión en Hacker News: Claude Skills are awesome, maybe a bigger deal than MCP
