La respuesta corta: Usa un skill cuando un flujo repetible vive en un solo archivo markdown. Usa un plugin cuando ese flujo depende de herramientas externas o quieres agrupar skills relacionados. Usa MCP cuando tu IA necesita hablar con un sistema vivo — una base de datos, un CRM, un canal de Slack — y quieres que esa conexión funcione en cualquier asistente, no solo en una plataforma.

Suena abstracto hasta que estás mirando un prompt que debería hacer algo útil, te das cuenta de que no puede acceder a tus herramientas, y te preguntas si escribir otro script desechable o construir un plugin completo para eso. Esta guía despeja la superposición para que puedas decidir rápido y seguir con tu día.

Por Qué Todo Esto Confunde Ahora Mismo

En aproximadamente un año y medio, Anthropic lanzó tres mecanismos de extensión diferentes. OpenAI adoptó el Model Context Protocol. Google siguió. Los nombres son vagos, las capacidades se solapan, y nadie ha publicado una comparación limpia que realmente ayude a un fundador independiente a decidir cuál instalar hoy.

Ves términos como skills, plugins, apps, app templates y servidores MCP usados indistintamente en documentación, artículos y anuncios de producto. Cuando estás intentando ahorrar tiempo en lugar de gastarlo leyendo notas de lanzamiento, esa ambigüedad tiene un costo real.

La buena noticia: estos mecanismos resuelven problemas diferentes. Una vez que los separas, la decisión se vuelve mecánica en lugar de misteriosa.

Skills: El Archivo de Instrucciones Reutilizable

Un skill es una carpeta con un archivo principal — SKILL.md — escrito en markdown plano con un pequeño encabezado YAML al inicio. Dentro, escribes instrucciones paso a paso que el asistente sigue. No se requiere código. No hay paso de compilación. En palabras de quienes lo definieron, es una guía de inducción para un nuevo empleado.

Un skill típico se ve así:

---
name: revisar-pr
description: Revisar un pull request por seguridad, pruebas y violaciones de estilo
---

# Revisión de Pull Request

1. Lee el diff del pull request actual.
2. Busca problemas comunes de seguridad.
3. Verifica que las funciones nuevas tengan pruebas.
4. Señala violaciones de la guía de estilo.
5. Publica comentarios de revisión en el PR.

Eso es todo. El asistente lee la descripción, decide cuándo usar el skill según lo que le pidas, y carga las instrucciones completas cuando coincide.

Los skills son la opción correcta cuando:

  • La tarea es autónoma y repetible — desplegar a staging, escribir un reporte de estado en formato fijo, revisar un PR, prepararte para una llamada de ventas.
  • Las instrucciones caben cómodamente en un solo archivo markdown.
  • No necesitas conectarte a una API externa o sistema vivo durante la ejecución.
  • Quieres compartir el flujo con un compañero de equipo sin obligarlo a leer un tutorial.

Los skills fallan cuando:

  • El flujo necesita extraer datos de una base de datos, publicar en Slack o leer de Google Drive. Los skills le dicen al asistente qué hacer — no le dan el alcance para hacerlo.
  • Estás intentando administrar una colección de flujos relacionados y mantenerlos sincronizados manualmente.
  • Necesitas instalaciones versionadas, metadatos o gestión de dependencias.

Piensa en un skill como una receta. Funciona perfectamente hasta que te das cuenta de que también necesitas un servicio de entrega de ingredientes, y la receta no lo incluye.

Plugins: El Paquete Instalable

Un plugin envuelve uno o más skills — y potencialmente otros componentes — en un paquete instalable único. Tiene un archivo de manifiesto, generalmente llamado plugin.json, con nombre, versión y descripción. Cuando lo instalas, todo lo que contiene llega junto: skills, agentes, hooks, comandos personalizados y, a veces, conexiones a servidores MCP.

Más allá de skills, un plugin puede incluir:

  • Agentes: Asistentes de IA especializados ajustados para trabajos específicos
  • Hooks: Acciones automatizadas disparadas por eventos, como ejecutar un linter después de cada edición
  • Conexiones a servidores MCP: Acceso empaquetado a Slack, Jira, una base de datos u otras herramientas externas
  • Comandos personalizados: Comandos slash que inician flujos de trabajo multi-paso

Los plugins son la opción correcta cuando:

  • Tienes una colección de skills relacionados que deberían viajar juntos — un paquete de “habilitación de ventas” podría agrupar preparación de llamadas, investigación de cuentas y análisis de negocios, más una conexión a CRM.
  • El flujo requiere integraciones con herramientas externas y no quieres configurar cada una por separado.
  • Quieres distribuir o versionar una capacidad completa, no solo un archivo de instrucciones.

Los plugins añaden complejidad cuando:

  • Tu necesidad es genuinamente una tarea ocasional. Instalar un plugin completo para un solo flujo es como comprar un libro de recetas cuando solo necesitas un plato.
  • Necesitas auditar qué permisos externos solicita el paquete. Los plugins pueden tener más superficie de ataque que un solo archivo de skill, especialmente cuando incluyen conexiones MCP o agentes personalizados.
  • Estás manteniendo múltiples plugins en un equipo y necesitas coordinar actualizaciones.

La analogía que realmente funciona: si un skill es una receta, un plugin es el libro de recetas. Útil cuando quieres toda la colección empaquetada juntos. Excesivo cuando solo necesitas un plato.

Servidores MCP: La Capa de Tuberías

El Model Context Protocol es un estándar abierto para conectar modelos de IA a sistemas externos. Se ejecuta sobre JSON-RPC 2.0 y fue diseñado para que un conector construido una vez funcione en cualquier cliente compatible — Claude Desktop, ChatGPT, Gemini y otros. Anthropic donó el protocolo a la Agentic AI Foundation bajo la Linux Foundation, cofundada con OpenAI y Block, lo que significa que ahora se gobierna como infraestructura neutral en lugar de software propietario.

Por dentro, MCP te ofrece tres cosas:

  • Herramientas: Funciones que la IA puede llamar, como consultar una base de datos o publicar en un webhook
  • Recursos: Datos legibles a los que la IA puede acceder, como archivos o documentos
  • Prompts: Plantillas de mensaje preconstruidas que la IA puede invocar

Los servidores MCP son la opción correcta cuando:

  • Tu IA necesita acceso en tiempo real a un sistema vivo — consultar Postgres, leer de Google Drive, interactuar con GitHub, extraer datos de un CRM, publicar en Slack.
  • Quieres una conexión que funcione entre múltiples asistentes, no solo en una plataforma.
  • Estás construyendo infraestructura a la que otras herramientas se conectarán, y quieres evitar el vendor lock-in.

MCP añade fricción cuando:

  • Solo necesitas instrucciones de comportamiento, no conectividad externa. Un skill maneja las instrucciones; MCP maneja las tuberías. No instales un servidor para un trabajo que un archivo markdown resuelve.
  • Estás configurando una aplicación anfitriona y necesitas entender la relación cliente-servidor antes de que algo funcione.
  • La seguridad y los permisos importan y no has auditado qué expone el servidor. Los servidores MCP tienen acceso amplio por diseño — ese es el punto. Ese también es el riesgo.

Si los skills son recetas y los plugins son libros de recetas, MCP es la cocina misma: la infraestructura que hace posible cocinar, invisible cuando funciona, catastrófico cuando está mal configurado.

Apps y App Templates: ¿Dónde Encajan?

OpenAI y otras plataformas han introducido apps y app templates como un formato de empaquetado de nivel superior. Una app típicamente agrupa skills, plugins y conexiones MCP en una unidad instalable única con su propia configuración e interfaz. Un app template es un punto de partida — una app preconstruida que puedes clonar y personalizar para tu propio flujo.

La tensión aquí es real: los app templates prometen velocidad, pero a menudo vienen con más capacidad de la que necesitas y menos control del que gustaría. Una template puede incluir cinco skills cuando solo necesitas uno, o integrar hardcodeado conectores que no usas. Está bien si estás dispuesto a pagar el impuesto de la complejidad innecesaria. Es caro si estás intentando mantener tu pila ligera.

Usa app templates cuando:

  • Quieres un punto de partida rápido y no te importa quitar piezas que no necesitas.
  • La template cubre exactamente el flujo que estás intentando replicar, y la personalización es mínima.

Omite los app templates cuando:

  • Puedes definir el flujo tú mismo en un solo archivo de skill en cinco minutos.
  • La template incluye integraciones que no usas y te preocupa la superficie de ataque o el costo.
  • Quieres visibilidad total de cada componente que se ejecuta cuando invocas la app.

El Marco de Decisión

Cuando estás intentando elegir entre estos mecanismos, empieza con la opción más simple que cubra el trabajo. Cada nivel arriba añade capacidad pero también añade complejidad, tiempo de configuración y carga de mantenimiento.

Hazte estas preguntas en orden:

  1. ¿Es este un flujo repetible con instrucciones claras? Si sí y no necesita herramientas externas, escribe un skill. Cinco minutos. Listo.

  2. ¿El flujo necesita llegar fuera de la conversación? Si sí, necesitas ya sea un servidor MCP para la conexión o un plugin que agrupe el servidor MCP y los skills juntos. Elige el plugin si quieres una instalación más fácil. Elige el servidor MCP directamente si quieres transparencia sobre qué pasa por dentro.

  3. ¿Tienes múltiples flujos relacionados que deberían viajar juntos? Agrúpalos en un plugin. Un plugin es el formato de envío correcto para una capacidad compartida en equipo.

  4. ¿Quieres algo preconstruido que puedas personalizar rápido? Considera una app o app template, pero audítalo primero. Quita lo que no necesitas antes de comprometerte con ello.

  5. ¿Es esta una tarea genuinamente ocasional? No construyas un skill para ello. No instales un plugin. Usa el asistente directamente y sigue adelante. No todo merece ser automatizado.

Escenarios Reales, Decisiones Reales

Así se ve esto en la práctica para fundadores y equipos pequeños:

Escenario A: Quieres que tu asistente revise cada PR antes de fusionarlo.

  • Escribe un skill. Las instrucciones describen el proceso de revisión. No se necesitan herramientas externas más allá de lo que el asistente ya tiene acceso. Este es un patrón de comportamiento, no un problema de conectividad.

Escenario B: Quieres que tu asistente extraiga métricas en vivo desde tu panel de análisis y las resuma para un reporte semanal.

  • Necesitas un servidor MCP conectado a tu API de análisis, o un plugin que incluya esa conexión MCP más un skill para formatear el reporte. Si ya tienes un servidor MCP para esa fuente de datos, el skill o el plugin es la opción más ligera.

Escenario C: Quieres que todo tu equipo siga el mismo flujo de inducción para nuevos empleados.

  • Empaqueta el flujo como un plugin. Agrupa los skills, las conexiones MCP requeridas y los comandos personalizados en una unidad instalable que tu equipo pueda agregar sin pedirte que lo expliques cada vez.

Escenario D: Encontraste una template en línea que hace el 80% de lo que necesitas.

  • Descárgala. Audita cada skill, cada conexión MCP, cada comando dentro. Quita lo que no usas. Personaliza lo que queda. Si al quitar piezas te quedas con un solo skill, has aprendido algo sobre tu propia pila — y te has ahorrado cargar peso muerto.

Qué No Construir

El error más grande que cometen los fundadores aquí no es elegir mal — es construir cuando no deberían. Cada skill, plugin y servidor MCP que agregas es algo que puede romperse, algo que tu equipo necesita aprender, algo que se desincroniza a medida que cambian las plataformas subyacentes.

Antes de escribir una sola línea de instrucción:

  • ¿Puede el asistente ya hacer esto con sus herramientas nativas?
  • ¿Este flujo ocurrirá más de dos veces por semana? Si no, un skill puede ser sobre-ingeniería.
  • ¿El cuello de botella es realmente la instrucción, o son los datos a los que el asistente no puede llegar? Si son los datos, necesitas conectividad, no un mejor prompt.
  • ¿Podrías lograr el mismo resultado cambiando cómo trabaja tu equipo, en lugar de automatizar el proceso actual?

La mejor extensión de IA es la que nunca tienes que mantener.

Preguntas Frecuentes

¿Puedo usar skills y servidores MCP juntos? Sí. Los skills le dicen al asistente qué hacer. Los servidores MCP le dan las herramientas para hacerlo. Una configuración típica combina ambos: un skill que describe el flujo y un servidor MCP que proporciona acceso a los sistemas externos de los que el flujo depende.

¿Los plugins van a reemplazar a los skills? No. Los plugins incluyen skills. No los reemplazan. La distinción es de empaquetado, no de capacidad.

¿Es MCP lo mismo que un plugin? No. MCP es un protocolo — las tuberías. Un plugin es un formato de empaquetado que puede incluir servidores MCP, skills y otros componentes. Operan en niveles diferentes de la pila.

¿Qué pasa si la plataforma que uso cambia cómo funcionan los skills o los plugins? Ese es un riesgo real. Todos estos mecanismos aún están evolucionando. La razón más sólida para preferir MCP y skills bien delimitados sobre formatos cerrados de plugins es que MCP es abierto y neutral respecto al proveedor. Cuando una plataforma cambia sus reglas de plugins, tus conexiones basadas en MCP siguen funcionando en otros lados.

¿Debo evaluar estas herramientas por cuánto tiempo ahorran, no por cuántas funciones tienen? Exactamente. El metrico que importa es: ¿esto elimina un dolor repetitivo sin añadir una carga de mantenimiento? Si la respuesta es sí, se gana su lugar. Si la respuesta es no, es ruido.

Fuentes