Publicar plugins de Claude: del repositorio al directorio

Cómo publicar plugins de Claude: la versión corta

Para publicar un plugin de Claude, siga esta secuencia:

1. Confirme que la cuenta de Claude que hará el envío tenga un plan Pro, Max, Team o Enterprise.
2. Elija la organización que deberá conservar la propiedad de la ficha a largo plazo.
3. Prepare el plugin con .claude-plugin/plugin.json, un README y una licencia.
4. Pruebe la carpeta en local y súbala a un repositorio de GitHub en el que la cuenta de GitHub conectada tenga permiso para hacer push.
5. Abra el portal para desarrolladores, seleccione Plugin bundle, indique el repositorio, la ruta opcional del plugin y la rama o etiqueta que se seguirá; después, ejecute Validate.
6. Complete la información sobre tratamiento de datos, cumplimiento, contacto y actualizaciones, y seleccione Submit for review.
7. Si el plugin apunta a un servidor MCP remoto que usted opera, cree un envío independiente de tipo MCP connector para ese servidor.

El repositorio puede seguir siendo privado durante la validación y la revisión si cumple las condiciones de acceso a GitHub y carga de código fuente de Anthropic. Antes de que el plugin se publique, deberá pasar a ser público.

Elija la ficha antes de entrar al portal

Un plugin y un conector están relacionados, pero no son intercambiables. El plugin funciona como un manual operativo empaquetado; el servidor MCP remoto es el equipo de servicio que hay detrás. Uno le enseña a Claude el flujo de trabajo. El otro le da acceso en tiempo real a su producto o sus datos.

Una skill no constituye un tercer tipo de envío: debe ir dentro de un paquete de plugin. Si ese paquete hace referencia a un servidor MCP alojado por usted, envíe ambos productos desde la misma organización de Claude y apúntelos a la misma URL del servidor. Así, el portal puede asociar las fichas y los usuarios no ven conjuntos de herramientas duplicados.

Decida quién será propietario de la ficha

Elegir la organización es una decisión de producto duradera, no un trámite administrativo. En un paquete de plugin, la primera organización que envía una carpeta de un repositorio conserva la ficha. Una segunda organización no puede enviar el mismo repositorio y la misma carpeta.

Las reglas de las cuentas son sencillas:

• Con Pro o Max, el envío se hace desde la propia cuenta.
• En Team o Enterprise, puede hacerlo un Owner.
• En Enterprise, un Owner puede conceder el permiso Directory mediante un rol personalizado.
• La cuenta de GitHub conectada dentro de esa organización de Claude debe poder hacer push al repositorio.

Si una agencia desarrolla el plugin, pero la identidad pública debe pertenecer al cliente, el envío debe hacerlo la organización del cliente. Transferir el repositorio más adelante no equivale a transferir la ficha del directorio.

Cuánto cuesta esta vía

Las instrucciones públicas de Anthropic no indican una tarifa independiente por aparecer en el directorio, pero una cuenta Free no puede hacer envíos. Por tanto, el desembolso mínimo es el plan de pago necesario para entrar.

• Quien trabaje en solitario y no tenga un plan de pago puede contratar Pro por $20 durante un mes con facturación mensual, o pagar $17 al mes con $200 por adelantado para un año.
• Team parte de dos personas. Dos plazas Standard cuestan $50 por un mes con facturación mensual, o $40 al mes con facturación anual.
• Max parte de $100 al mes, pero no es necesario solo para hacer el envío.

El trabajo de lanzamiento supone el mayor gasto. Un producto alojado requiere dos envíos preparados: uno para el paquete y otro para el conector. Además, un plugin necesita un manifiesto estable, un README de al menos 40 palabras, una licencia, respuestas sobre tratamiento de datos, un contacto para la revisión y un repositorio que pueda hacerse público. El nuevo portal reduce la carga de coordinación al reunir validación, resultados del análisis, estado de revisión, publicación, actualizaciones y uso. No elimina ese trabajo.

Prepare un paquete de plugin listo para el directorio

Un paquete mínimo y creíble tiene esta estructura:

your-plugin/
  .claude-plugin/plugin.json
  skills/your-workflow/SKILL.md
  README.md
  LICENSE

El manifiesto necesita un name permanente en minúsculas, un displayName pensado para personas, una version, una description útil, un autor y una declaración de licencia o un archivo de licencia independiente. Elija con cuidado el nombre permanente. Puede cambiar displayName, pero el nombre del manifiesto define la identidad del plugin.

El README no es mero mantenimiento del repositorio. El directorio lo utiliza como material de la ficha, y la validación bloquea cualquier plugin cuyo README tenga menos de 40 palabras que no sean código. Explique qué hace el plugin, cómo se utiliza y qué datos envía. No incluya credenciales reales en el repositorio.

Si el paquete hace referencia a un servidor remoto, coloque el endpoint HTTPS en .mcp.json. No incluya allí claves de API: todas las personas que instalen el plugin recibirán esos archivos.

Pruebe en local y vuelva a validar en el portal

La validación local detecta archivos de plugin mal formados antes de involucrar a GitHub:

claude plugin validate ./your-plugin
claude --plugin-dir ./your-plugin

El primer comando comprueba la sintaxis y el esquema de los archivos. El segundo inicia una sesión de Claude Code con la carpeta de trabajo cargada, para que pueda probar sus skills y comandos. La validación local no sustituye al botón Validate del portal. El portal también comprueba los requisitos del directorio, la estructura del repositorio, los conflictos de nombres, la política de archivos y otras reglas de envío.

Para este recorrido se creó un pequeño plugin llamado release-note-builder, con una skill y tres archivos de incidencias sintéticas: una nueva exportación CSV del registro de auditoría, mejoras de paginación y la corrección de correos duplicados. Claude Code 2.1.283 devolvió Validation passed, código de salida 0, sin errores ni advertencias.

Después se cargó la carpeta con claude --plugin-dir para una prueba con datos preparados. La máquina no tenía una sesión autenticada de Claude, así que la solicitud se detuvo con Not logged in · Please run /login antes de llamar a un modelo. No se observó ninguna nota de versión generada. El límite es importante: la validación de la carpeta puede ejecutarse en local, pero para probar el comportamiento se necesita acceso autenticado al modelo. Para un flujo de pruebas de comportamiento más completo, consulte la guía independiente sobre evaluaciones de plugins de Claude Code.

Complete el envío del plugin

La documentación pública organiza el portal en seis etapas prácticas.

1. Fuente

Introduzca el repositorio de GitHub como URL o con el formato owner/repo. Añada la ruta del plugin si se encuentra por debajo de la raíz del repositorio. Elija una rama o etiqueta para las próximas versiones, o deje el campo vacío para seguir la rama predeterminada. Después, seleccione Validate.

La validación lee un solo commit. Si sube una corrección, seleccione Re-validate para que el informe analice el nuevo commit.

2. Datos de la ficha

El portal genera la ficha a partir de plugin.json y el README. Si el nombre, la descripción o la explicación no son correctos, edite los archivos del repositorio y vuelva a validar. Es una disciplina útil: la promesa pública y el paquete distribuido permanecen en la misma versión.

3. Tratamiento de datos

Indique si el plugin lee o almacena datos personales, envía datos a destinos distintos de sus conectores declarados, conserva datos o está pensado para menores de 18 años. Estas respuestas forman parte del contrato del producto; no son simples campos para completar.

4. Cumplimiento y contacto

Facilite un correo electrónico que Anthropic pueda utilizar durante la revisión y complete las cuatro confirmaciones obligatorias. El portal puede devolver una versión con observaciones o cambios solicitados, así que use una bandeja de entrada que alguien supervise de verdad.

5. Actualizaciones

Elija entre el webhook predeterminado para los push de GitHub o únicamente las comprobaciones programadas. Ambas opciones permiten que el directorio vigile la rama o etiqueta seleccionada. Para configurar el webhook se necesita acceso de administrador al repositorio.

6. Revisión y envío

Confirme los datos y seleccione Submit for review. Una organización puede crear hasta 10 envíos en 24 horas; los borradores y los envíos retirados también cuentan. No cree duplicados cuando lo que necesita es continuar un borrador existente.

Envíe el servidor MCP remoto por separado

Si el plugin llama a un servidor MCP remoto que usted opera, vuelva a Submit new y elija MCP connector. La ruta del conector solicita más detalles operativos porque Anthropic va a incluir un servicio activo, no una carpeta.

Prepare la URL del servidor, las URL de la documentación y la política de privacidad, un icono, credenciales de prueba para el revisor y cualquier imagen del carrusel de la MCP App. El flujo documentado abarca la conexión, las herramientas sincronizadas, la ficha pública, los casos de uso, la empresa, la autenticación, el tratamiento de datos, las instrucciones de prueba, el cumplimiento y la revisión final.

Los campos de la ficha pública incluyen un nombre de servidor de hasta 100 caracteres, una descripción de una línea de hasta 200 caracteres, una descripción extensa de hasta 2,000 caracteres, de una a cinco categorías, documentación, privacidad, soporte, icono y un slug de URL permanente. Si el producto requiere una cuenta, los revisores también necesitan una cuenta de prueba con datos. No dé por listo un conector solo porque su endpoint de estado responde. Pruebe cada herramienta con MCP Inspector o como conector personalizado en Claude.

Lea el estado como una cola de acciones

No existe un plazo de revisión prometido. La pregunta útil no es «¿Cuánto tarda la revisión?», sino «¿Quién debe actuar ahora?».

Approved no significa que el plugin pueda instalarse. Published, sí. La configuración predeterminada puede seguir exigiendo que un revisor de Anthropic publique una versión aprobada. Más adelante, algunos plugins pueden configurarse para publicar automáticamente las actualizaciones que superen las comprobaciones, pero una versión retenida sigue esperando.

Planifique las actualizaciones antes del primer lanzamiento

Después de publicar, integre los cambios en la rama seguida o mueva la etiqueta seleccionada. El directorio lee el nuevo commit, lo valida, lo somete al análisis de seguridad y lo muestra como otra versión. Incremente version en plugin.json con cada lanzamiento.

Una actualización fallida o retenida no retira la ficha que funciona. El directorio sigue ofreciendo la última versión publicada hasta que la sustituta sale a producción. Así, la rama funciona como un canal de lanzamientos, no solo como almacenamiento del código fuente.

La pestaña Usage cierra el ciclo de aprendizaje. Puede mostrar instalaciones, cuentas activas, retención, distribución por versión, uso de componentes, errores de carga, llamadas MCP y latencia, vistas de la ficha, clics de instalación e instalaciones durante un periodo seleccionado de hasta 90 días. Las cifras se actualizan una vez al día en UTC y pueden exportarse como CSV. No prometa una cifra de instalaciones antes de que el portal la haya registrado.

Los seis equipos que más pueden aprovecharlo

1. Equipos SaaS con un producto MCP remoto

El equipo de producto envía el servidor activo como conector y empaqueta como plugin una skill que articula el flujo de trabajo. Los clientes reciben acceso a las herramientas junto con las instrucciones que les dan utilidad. El equipo obtiene el estado del servidor y el uso de herramientas desde el conector, y las instalaciones y el uso de componentes desde el plugin.

2. Empresas de software para flujos de trabajo

Una plataforma de gastos, selección de personal, soporte o ventas puede convertir su mejor procedimiento operativo en una skill y combinarla con el conector del producto. El beneficio está en la calidad de la adopción: los usuarios incorporan un flujo de trabajo, no un conjunto de métodos de API sin explicación.

3. Responsables de plugins de código abierto

Quien mantiene un plugin puede conservar el código público, seguir la rama de lanzamientos y usar el portal como ficha estable y canal de actualizaciones. La última versión aprobada permanece disponible mientras se corrige un nuevo commit, lo que reduce la presión de que cada push al repositorio esté listo de inmediato para los usuarios.

4. Agencias que entregan plugins a clientes

Una agencia puede desarrollar y probar la carpeta, pero, si el cliente debe ser propietario de la ficha, el envío tiene que hacerlo la organización del cliente. El resultado es un traspaso más ordenado: el control del repositorio, la propiedad en el directorio, el contacto de soporte y las analíticas quedan en manos del comprador, no del proveedor.

5. Equipos de plataformas empresariales

Un Owner de Enterprise puede conceder a determinadas personas el permiso Directory sin compartir un rol amplio de propietario. Así, el equipo separa el trabajo de lanzamiento de la administración general de la organización y mantiene la ficha dentro de la organización de la empresa.

6. Creadores de herramientas para Claude Code que quieren salir de la terminal

Un comando o una skill puede llegar al directorio más amplio, pero antes hay que comprobar qué superficies admite. Las skills funcionan en chat, Cowork y Claude Code. Los agentes y hooks no se ejecutan en chat, los servidores MCP locales tampoco, y los servidores LSP siguen siendo exclusivos de Claude Code. La ventaja es evitar una ficha que prometa la misma experiencia en todas partes cuando el paquete no puede ofrecerla.

Tres productos que vale la pena crear alrededor del portal

1. Plugin Release Gate, la mejor oportunidad

Cree una comprobación de GitHub que inspeccione el plugin antes de que una rama de lanzamiento llegue al portal. Ejecutaría la validación local, confirmaría el README y la licencia, marcaría combinaciones de componentes no admitidas, compararía la versión del manifiesto y generaría un informe de preparación para el directorio.

La demanda ya es visible: claude code plugins recibe cerca de 5,400 búsquedas mensuales en Estados Unidos, con intención comercial y un CPC de $6.22. La versión mínima vendible sería una GitHub App acompañada de un informe web y una insignia para el repositorio. La salvedad es importante: no puede prometer con honestidad la aprobación del portal, porque las comprobaciones del directorio de Anthropic y la revisión humana van más allá del comando local. Su valor está en reducir fallos evitables, no en garantizar la aceptación.

2. Optimizador de fichas del directorio

Cree una capa de informes que importe la exportación CSV del portal y convierta las vistas, los clics de instalación, las instalaciones, las fuentes de descubrimiento, las versiones y el uso de componentes en recomendaciones para la ficha y los lanzamientos. El comprador es quien publica un plugin con tráfico suficiente para que los datos diarios resulten útiles.

claude plugins recibe cerca de 8,100 búsquedas mensuales en Estados Unidos, tiene intención comercial y un CPC de $9.05. Un MVP necesita carga de CSV, cálculos del embudo, comparación de versiones y una lista semanal de acciones. El obstáculo es el arranque en frío: antes de la publicación y del uso real, el producto no tiene datos propios que analizar. También depende de una exportación, no de una API de analíticas documentada.

3. Auditor de plugins para varias superficies

Cree un escáner estático que indique exactamente qué cargarán Chat, Cowork y Claude Code desde una misma carpeta de plugin. Debería señalar un directorio bin/ en el nivel superior, supuestos sobre MCP local, agentes y hooks ignorados por el chat y servidores LSP exclusivos de Claude Code; después, generaría una matriz de pruebas.

claude-plugins marketplace recibe cerca de 1,900 búsquedas mensuales en Estados Unidos, con dificultad 16 e intención comercial. El MVP es un escáner de repositorios respaldado por la tabla de compatibilidad de Anthropic. El reto es el mantenimiento: la compatibilidad de la plataforma cambiará, y a quienes solo crean para la terminal quizá no les interese una cobertura más amplia.

El release gate es la mejor apuesta porque interviene en cada versión, no solo en la primera ficha. Además, complementa el portal en lugar de intentar sustituirlo.

Lo que el portal no resuelve

No vuelve útil un plugin débil. La validación puede demostrar que los archivos están bien formados y cumplen las políticas, pero no que una skill mejora los resultados. Tampoco garantiza que los componentes se comporten igual en todas las aplicaciones de Claude. No ofrece un plazo fijo de revisión, una etiqueta Verified bajo solicitud ni una audiencia de instalación desde el primer día.

Tampoco convierte un producto MCP alojado en una sola ficha. La separación del conector es deliberada: la autenticación, el estado, las herramientas y las políticas del servidor necesitan su propio registro operativo.

La experiencia unificada de descubrimiento todavía se está desplegando durante las semanas posteriores al lanzamiento del 25 de septiembre. Publique para las superficies que ya están documentadas y considere la distribución más amplia como un canal que está por llegar, no como alcance actual que pueda prometer.

Qué hacer el lunes

Elija la organización de Claude que deberá ser propietaria de la ficha. Convierta un flujo de trabajo real en un paquete de plugin, asígnele un nombre de manifiesto estable, un README útil y una licencia; después, ejecute la validación local. Si llama a un servidor MCP alojado por usted, prepare en paralelo el envío del conector. No abra el portal hasta que la decisión sobre la propiedad y la ruta del repositorio sean definitivas.

Si busca construir un plugin y su conector de producción como un solo sistema de lanzamiento sólido, consulte sistemas de IA en producción.