Plugins y MCP en Claude Code: qué son y cuándo usar cada uno

Los tres términos aparecen en la misma frase constantemente y se usan como si fueran intercambiables. No lo son, y confundirlos lleva a dos errores caros: montar un servidor MCP para algo que resolvía un archivo de texto, o pelearse durante horas con un prompt para algo que necesitaba acceso real a un sistema.

Tres piezas, tres problemas distintos

La progresión natural es de izquierda a derecha, y conviene no saltarse pasos. Casi nadie necesita empezar por la derecha.

Plugins: empaquetar lo que ya funciona

Un plugin es un paquete instalable que puede incluir varias cosas a la vez: uno o más skills, comandos propios, automatismos que se disparan al ocurrir algo (por ejemplo, formatear al guardar) y la configuración de servidores MCP.

Se instalan desde el menú /plugin, que lista los marketplaces configurados. La ventaja frente a mandar instrucciones por Slack es evidente: se versiona, se actualiza y todo el equipo tiene la misma versión.

El momento de empaquetar en plugin llega cuando se cumplen dos condiciones:

• Tienes tres o más skills que se usan juntos y que se explican mal por separado.
• Hay más de una persona que los necesita, y ya te has cansado de explicar la instalación.

Si tienes un skill y trabajas solo, un plugin es burocracia. Deja el skill en .claude/skills/ y sigue con tu vida.

MCP: conectar con el mundo exterior

MCP —Model Context Protocol— es un estándar abierto que resuelve un problema de combinatoria. Antes, cada asistente necesitaba una integración propia para cada herramienta: N modelos por M herramientas, N×M integraciones. Con un protocolo común, cada herramienta expone un servidor y cualquier asistente compatible puede usarlo.

En la práctica, un servidor MCP le da al asistente tres tipos de cosas:

• Herramientas que puede invocar: consultar una tabla, crear una incidencia, buscar en una wiki.
• Recursos que puede leer: archivos, documentos, registros.
• Plantillas de instrucciones que el servidor propone para su dominio.

Lo interesante no es la conexión en sí, es lo que habilita: dejar de ser el humano que copia datos de un sistema a otro. «Mira las incidencias abiertas de esta semana, agrúpalas por causa raíz y escribe el resumen para el comité» es una tarea que sin MCP implica exportar un CSV, y con MCP no implica nada.

El precio es real: hay que instalar y mantener el servidor, gestionar credenciales y decidir permisos. Por eso el criterio es sencillo: monta un MCP cuando el trasiego manual de datos te cueste más de una hora a la semana. Por debajo de eso, no compensa.

Cuándo usar cada cosa

Las señales que indican qué necesitas de verdad:

• «Lo explico igual cada vez» → skill.
• «Cada uno lo hace a su manera» → skill en el repositorio del proyecto.
• «Explicar la instalación me lleva media hora» → plugin.
• «Exporto este informe cada lunes para pegarlo en otro sitio» → MCP.
• «Tengo que abrir cuatro pestañas para responder una pregunta» → MCP.
• «El resultado sale bien pero en un formato distinto cada vez» → no necesitas nada de esto: necesitas fijar el formato en el prompt.

Lo que hay que revisar antes de dar permisos

Un asistente con acceso de escritura a tus sistemas es un asistente que puede equivocarse con consecuencias. Cuatro reglas que evitan la mayoría de los disgustos:

1. Lectura primero. Empieza con permisos de solo lectura y añade escritura cuando tengas evidencia de que hace falta. La mayoría del valor está en leer y correlacionar.
2. Todo lo que entra son datos, no órdenes. Una incidencia, un correo o una página web pueden contener texto redactado para que el asistente lo interprete como instrucción. Si un contenido externo «pide» borrar algo, enviar algo o cambiar permisos, eso se enseña al humano, no se ejecuta.
3. Credenciales acotadas. Un token de servicio con el alcance mínimo, no tu usuario de administrador. Y rotable.
4. Confirmación en lo irreversible. Borrar, enviar, publicar, pagar: que siempre pase por una confirmación humana explícita, aunque ralentice.

Con los plugins, la analogía útil es la de una dependencia de software: instalas código de un tercero que se ejecutará en tu máquina. Lo mismo que harías con un paquete de npm o de Composer —mirar quién lo mantiene, qué trae, si está actualizado— aplica aquí.

Por dónde empezar sin liarla

1. Semana 1: un skill para la tarea que más repites. Nada más.
2. Semana 2: dos o tres skills más y mueve al repositorio los que afecten al equipo.
3. Semana 3: mira si algún flujo se repite lo suficiente para empaquetarlo en plugin.
4. Cuando duela de verdad: el MCP del sistema entre el que estás copiando datos a mano. Solo lectura al principio.

Si estás en la casilla de salida, empieza por qué son los skills y por el catálogo de skills para desarrollo, que es donde hay más recursos de este tipo ya probados.