El marketplace oficial de plugins de Claude Code de Anthropic ya no es un rumor enterrado en carpetas de configuración. El repo público de GitHub, anthropics/claude-plugins-official, tiene más de 30.000 estrellas a fecha del 17 de junio de 2026, y su README describe un directorio curado con plugins internos de Anthropic además de entradas de terceros. Ese mismo README también incluye la frase que debería marcar tu postura: “Make sure you trust a plugin before installing, updating, or using it” porque Anthropic no controla todos los servidores MCP, archivos u otras dependencias incluidas en esos plugins (GitHub).
Esa advertencia no es letra pequeña legal. Un plugin de Claude Code puede incluir slash commands, skills, agentes, hooks, servidores MCP, servidores LSP, ejecutables y ajustes. En términos simples para desarrolladores: puede añadir contexto al prompt, iniciar procesos locales, llamar a servicios remotos, ejecutar hooks de shell en eventos del ciclo de vida y exponer nuevas herramientas al modelo.
El modelo mental correcto no es “instalar un tema para el editor”. Es “añadir una dependencia que puede ejecutar código cerca de mi árbol de código fuente”.
El Marketplace Es Real, Pero “Oficial” No Significa “Seguro a Ciegas”
Anthropic anunció los plugins de Claude Code el 9 de octubre de 2025, describiéndolos como colecciones de slash commands, agentes, servidores MCP y hooks instalables con /plugin (Claude blog). La documentación actual de Claude Code dice que el marketplace oficial de Anthropic, claude-plugins-official, está disponible automáticamente cuando Claude Code arranca, y que puedes instalar un plugin con:
/plugin install github@claude-plugins-officialSi falta el plugin, la documentación te indica que actualices el marketplace con:
/plugin marketplace update claude-plugins-officialo que lo añadas con:
/plugin marketplace add anthropics/claude-plugins-officialEse es el camino feliz oficial (Claude Code docs). Es útil. También está incompleto como política operativa.
El archivo de marketplace del repo oficial apunta a una mezcla de directorios locales de plugins y fuentes externas fijadas por commit SHA. Por ejemplo, las entradas pueden referenciar repositorios de GitHub, subdirectorios, refs y SHAs en .claude-plugin/marketplace.json (raw marketplace file). Fijar versiones ayuda, pero no elimina la necesidad de inspeccionar qué hace el código fijado. Un plugin puede seguir lanzando un servidor, pedir credenciales, ejecutar hooks o depender de un binario cuyo comportamiento cambia fuera del manifiesto del marketplace.
La comunidad ha notado lo mismo. En un hilo reciente de r/ClaudeAI que preguntaba por plugins importantes de Claude Code, una respuesta recomendaba CLAUDE.md y hooks primero, y solo después servidores MCP específicos del proyecto. Otra advertía contra “lanzarle conectores aleatorios” a Claude Code porque cuestan tokens y pueden contaminar el contexto (Reddit). Ese es el debate práctico ahora: los plugins son potentes, pero cada capacidad extra trae una superficie de coste.
Empieza Por el Manifiesto, Luego Lee el Repo
Tu primer objetivo de auditoría es la fuente del plugin. No instales desde fragmentos de búsqueda, comandos copiados de blogs o agregadores aleatorios de marketplaces hasta que puedas rastrear la fuente hasta un repo y un manifiesto.
En el repo del marketplace oficial, revisa:
- La entrada del marketplace en
.claude-plugin/marketplace.json - El tipo de
source, URL, ruta, ref y SHA - El
.claude-plugin/plugin.jsondel plugin, si existe - Cualquier
.mcp.json,.lsp.json,hooks/hooks.json,commands/,skills/,agents/,bin/y scripts
La referencia de plugins de Anthropic enumera las rutas principales de los componentes. Los hooks viven en hooks/hooks.json, los servidores MCP pueden vivir en .mcp.json, los ejecutables pueden vivir en bin/, y los manifiestos de plugins pueden apuntar a ubicaciones personalizadas de componentes (Claude Code plugin reference). Eso significa que “he revisado plugin.json” no basta. Un plugin puede apoyarse en rutas de descubrimiento por defecto.
Una revisión manual rápida se ve así:
git clone https://github.com/OWNER/PLUGIN-REPO /tmp/plugin-audit
cd /tmp/plugin-audit
find . -maxdepth 3 \( \
-name plugin.json -o \
-name hooks.json -o \
-name .mcp.json -o \
-name .lsp.json -o \
-path "*/bin/*" -o \
-path "*/scripts/*" \
\) -print
rg -n "curl|wget|bash|sh -c|chmod|open |xdg-open|osascript|token|api_key|secret|eval|exec|spawn|subprocess"Ese comando rg es bruto, pero aquí lo bruto viene bien. Buscas sorpresas en tiempo de instalación, ejecución de shell, lanzamientos de navegador, descargas remotas, manejo de credenciales y scripts que mutan tu repo o tu directorio home.
Mi regla: si un plugin necesita un script de shell para hacer su trabajo principal, quiero entender cada comando de ese script antes de instalar. Si descarga otro artefacto en tiempo de ejecución, trato ese artefacto de runtime como parte del plugin.
Los Servidores MCP Son la “Comodidad” Más Cara
MCP es donde la comodidad de los plugins puede convertirse en coste oculto. La documentación MCP de Anthropic dice que los servidores MCP definidos por plugins arrancan automáticamente cuando el plugin está habilitado, y que las herramientas MCP del plugin aparecen junto a las herramientas MCP configuradas manualmente (Claude Code MCP docs). La documentación también dice que los servidores MCP de plugins usan las mismas variables de entorno que los servidores configurados manualmente, lo cual importa si tu shell exporta tokens de cloud, URLs de bases de datos o credenciales de servicios internos.
La queja de la comunidad es concreta: los esquemas de herramientas MCP pueden comerse contexto antes de que llames a una herramienta. En un hilo de r/ClaudeCode sobre sobrecarga de tokens, usuarios apuntaron a plugins deshabilitados y a la ausencia de servidores MCP pesados como posible razón de un menor consumo de tokens, y un comentarista llamó a los esquemas de herramientas MCP “un enorme coste oculto” (Reddit). En otro hilo, un comentarista afirmó que los servidores MCP conectados registran esquemas de herramientas en el contexto y recomendó podar servidores por sesión (Reddit).
Trata las estimaciones exactas de tokens de Reddit como anecdóticas salvo que las reproduzcas en tu propio entorno. La dirección de fondo sigue siendo correcta: un servidor siempre activo con muchas herramientas verbosas no sale gratis.
Usa esta tabla de decisión antes de instalar un plugin estilo conector:
| Necesidad | Opción más segura por defecto | Usa MCP cuando |
|---|---|---|
| Ejecutar operaciones de GitHub | CLI gh vía Bash | Claude deba navegar issues, PRs y metadatos de forma interactiva |
| Consultar una base de datos | CLI de solo lectura o script local | Claude necesite llamadas estructuradas a herramientas con credenciales acotadas |
| Inspeccionar recursos cloud | CLI del proveedor con comandos explícitos | El servidor MCP tenga permisos estrechos y logs de auditoría claros |
| Obtener documentación | Docs estáticas, archivos del repo o enlaces web | Los recursos sean grandes, dinámicos y se referencien con frecuencia |
| Aplicar una política | Hook PreToolUse | La decisión necesite contexto visible para Claude o metadatos de herramientas |
Una herramienta CLI suele ser más segura porque se invoca solo cuando hace falta y produce salida solo para ese turno. MCP puede ser más seguro cuando te da OAuth acotado, herramientas tipadas y logs de auditoría. El error es instalar MCP por reflejo.
Los Hooks Merecen Su Propia Revisión de Seguridad
Los hooks son la función que hace que los plugins parezcan mágicos. También son la función que audito con más dureza.
Los hooks de Claude Code pueden ejecutarse en eventos como SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PreCompact y SessionEnd. La referencia de plugins dice que los tipos de hooks incluyen hooks de comando, hooks HTTP, hooks de herramientas MCP, hooks de prompt y hooks de agente (Claude Code plugin reference). La guía de hooks explica que un hook PreToolUse puede bloquear una acción saliendo con código 2, mientras que el stdout de UserPromptSubmit, UserPromptExpansion y SessionStart puede añadirse al contexto de Claude (Claude Code hooks guide).
Eso es mucho poder.
Un buen hook bloquea comportamientos peligrosos o añade contexto compacto y determinista. Un mal hook convierte cada prompt en un pipeline RAG caro, filtra el texto del prompt a un endpoint HTTP o cambia tu entorno en silencio.
Audita hooks con cuatro preguntas:
- ¿Qué evento lo dispara?
- ¿Qué matcher lo limita?
- ¿Qué datos recibe?
- ¿Qué escribe en stdout, stderr, disco, red o contexto?
La comunidad está dividida aquí de una forma útil. En un hilo de r/ClaudeCode sobre hooks, algunos desarrolladores describen los hooks como la única forma fiable de hacer cumplir reglas, bloquear malas acciones de git o recordar a Claude que escriba memoria. Otros están construyendo flujos elaborados de memoria y RAG sobre UserPromptSubmit (Reddit). Ambas cosas pueden ser válidas. La diferencia está en el presupuesto y el radio de explosión.
Para instalaciones de equipo, permitiría hooks de política antes que hooks de inyección de contexto. Un hook PreToolUse que bloquea patrones rm -rf es fácil de razonar. Un hook UserPromptSubmit que obtiene e inyecta memoria en cada turno necesita mediciones, límites y ownership claro.
Instala de Forma Estrecha, Mide y Luego Promociona
Claude Code admite scopes de plugin de usuario, proyecto, local y gestionado. La documentación describe el scope de usuario como personal entre proyectos, el scope de proyecto como compartido mediante .claude/settings.json, y el scope local como específico del proyecto pero no compartido (Claude Code docs).
Usa esos scopes como mecanismo de despliegue:
- Instala primero en local.
- Ejecuta una tarea real.
- Revisa los detalles de
/pluginy/mcp. - Usa
/contexty/usageantes y después. - Deshabilita cualquier cosa que no se gane su sitio.
- Promociona a scope de proyecto solo después de revisarla.
La documentación ahora dice que el panel de detalles del plugin puede mostrar estimaciones de coste de contexto en Claude Code v2.1.143 y posteriores, fechas de última actualización en v2.1.144 y posteriores, y un inventario “Will install” en v2.1.145 y posteriores (Claude Code docs). Usa ese inventario antes de pulsar instalar. Si un plugin dice ser un formateador pero instala un servidor MCP, un hook y un monitor en segundo plano, para e inspecciona.
Presta atención también a las actualizaciones automáticas. Anthropic dice que los marketplaces oficiales tienen auto-update habilitado por defecto, mientras que los marketplaces de terceros y locales lo tienen deshabilitado por defecto. La documentación también describe DISABLE_AUTOUPDATER y FORCE_AUTOUPDATE_PLUGINS para controlar el comportamiento de actualización (Claude Code docs). El auto-update es cómodo para parches de seguridad, pero cambia tu cadena de suministro en runtime. Para equipos regulados, fija versiones del marketplace en un marketplace interno revisado en vez de dejar que cada portátil derive por su cuenta.
La Checklist Que Uso Antes de Instalar
Esta es la versión corta que le daría a cualquier desarrollador de un equipo que use Claude Code.
Fuente:
- ¿El marketplace es
anthropics/claude-plugins-official, un repo interno o un repo de terceros? - ¿La fuente del plugin está fijada a un SHA?
- ¿La homepage coincide con el propietario de la fuente?
- ¿El repo tiene cambios recientes inesperados, blobs generados o scripts de instalación?
Componentes:
- ¿Añade servidores MCP?
- ¿Añade hooks?
- ¿Añade ejecutables en
bin/? - ¿Añade agentes que pueden llamar a herramientas?
- ¿Añade servidores LSP que requieren binarios locales?
Permisos:
- ¿Qué credenciales solicita?
- ¿Los valores sensibles se almacenan mediante
userConfigdel plugin como campos sensibles? - ¿El servidor MCP obtiene acceso de solo lectura o de escritura?
- ¿Algún hook llama a casa por HTTP?
- ¿Algún script hereda variables de entorno amplias?
Coste:
- ¿Qué reporta
/plugincomo coste de contexto? - ¿Qué cambia en
/contextdespués de habilitarlo? - ¿El plugin aporta valor en cada sesión, o solo durante flujos raros?
- ¿Podría un comando CLI producir el mismo resultado con menos contexto persistente?
Operaciones:
- ¿Puedes deshabilitarlo limpiamente con
/plugin disable name@marketplace? - ¿Puedes desinstalarlo limpiamente?
- ¿Deja atrás configuración, credenciales, daemons, cachés o autenticación de navegador?
- ¿Quién es dueño de las actualizaciones?
- ¿Qué se rompe si la fuente del plugin desaparece?
La respuesta con opinión: instala menos plugins de los que quieres. Prefiere plugins pequeños y aburridos que añadan un solo flujo de trabajo. Prefiere CLIs para operaciones puntuales. Usa MCP cuando el servidor esté acotado, auditado y sea realmente interactivo. Usa hooks como guardarraíles, no como vertedero de cada preferencia que desearías que el modelo recordara.
Los plugins se están convirtiendo en el formato de paquetes de Claude Code para flujos de trabajo. Eso es bueno. Significa que los equipos pueden compartir configuraciones repetibles en vez de folklore tribal de prompts. Pero el formato de paquete es lo bastante potente como para merecer revisión de dependencias, revisión de permisos y revisión de coste. Si no harías curl | bash de una herramienta dentro de tu repo sin leerla, no instales su versión en plugin solo porque aparezca en una interfaz amable de marketplace.
Pie discreto: Si quieres probar Claude Fable 5 por tu cuenta, puedes usarlo mediante Claude Fable 5 on OneHop, un endpoint drop-in con un precio alrededor de un 30% por debajo de lista. Las cuentas nuevas pueden empezar con $10 gratis, sin tarjeta.
Lectura adicional: Getting started with Claude Fable 5.
