Plugins Claude: como publicar no diretório oficial

Como publicar plugins Claude: resposta rápida

Para publicar um plugin Claude, siga esta sequência:

1. Confirme que a conta do Claude usada no envio está em um plano Pro, Max, Team ou Enterprise.
2. Escolha a organização que deverá manter a propriedade da publicação no longo prazo.
3. Monte o plugin com .claude-plugin/plugin.json, um README e uma licença.
4. Teste a pasta localmente e depois coloque-a em um repositório do GitHub para o qual a conta conectada tenha permissão de push.
5. Abra o portal para desenvolvedores, escolha Plugin bundle, informe o repositório, o caminho opcional do plugin e a branch ou tag monitorada; depois, execute Validate.
6. Preencha as configurações de tratamento de dados, conformidade, contato e atualizações; em seguida, selecione Submit for review.
7. Se o plugin apontar para um servidor MCP remoto operado por você, crie um envio separado do tipo MCP connector para esse servidor.

O repositório pode permanecer privado durante a validação e a análise, desde que você cumpra as condições de acesso ao GitHub e envio do código-fonte da Anthropic. Antes de o plugin entrar no ar, o repositório precisa ser público.

Escolha o tipo de publicação antes de abrir o portal

Plugin e conector se relacionam, mas não são intercambiáveis. Pense no plugin como um manual de operação pronto para uso e no servidor MCP remoto como a equipe de atendimento por trás dele. Um ensina o fluxo de trabalho ao Claude; o outro dá ao Claude acesso em tempo real ao seu produto ou aos seus dados.

Um skill não é um terceiro tipo de envio. Coloque-o dentro de um pacote de plugin. Se esse pacote fizer referência ao seu servidor MCP hospedado, envie os dois produtos pela mesma organização do Claude e aponte ambos para a mesma URL do servidor. Assim, o portal consegue associar as publicações e os usuários não veem conjuntos duplicados de ferramentas.

Defina quem será o proprietário da publicação

A escolha da organização é uma decisão duradoura de produto, não um detalhe administrativo. No caso de um pacote de plugin, a primeira organização que envia uma pasta de repositório fica com a publicação. Uma segunda organização não pode enviar o mesmo repositório e a mesma pasta.

As regras para a conta são simples:

• Nos planos Pro ou Max, o envio é feito pela sua própria conta.
• Nos planos Team ou Enterprise, um Owner pode fazer o envio.
• No Enterprise, um Owner pode conceder a permissão Directory por meio de uma função personalizada.
• A conta do GitHub conectada dentro dessa organização do Claude precisa ter permissão para fazer push no repositório.

Se uma agência desenvolver o plugin, mas o cliente tiver de ser o dono da identidade pública, o envio deverá partir da organização do cliente. Transferir um repositório depois não equivale a transferir a publicação no diretório.

Quanto custa publicar

As instruções públicas da Anthropic não informam uma taxa específica para publicar no diretório, mas uma conta Free não pode fazer o envio. Portanto, o custo mínimo em dinheiro é o plano pago necessário para abrir essa porta.

• Quem trabalha sozinho e ainda não tem um plano pago pode usar o Pro por $20 em um mês com cobrança mensal ou por $17 ao mês, com $200 pagos antecipadamente pelo ano.
• O Team começa com duas pessoas. Duas licenças Standard custam $50 por um mês com cobrança mensal ou $40 ao mês na cobrança anual.
• O Max começa em $100 por mês, mas não é necessário ter Max apenas para fazer o envio.

O custo maior está no trabalho de lançamento. Um produto hospedado exige dois envios preparados: um para o pacote e outro para o conector. O plugin também precisa de um manifesto estável, um README com no mínimo 40 palavras, uma licença, respostas sobre o tratamento de dados, um contato para a análise e um repositório que possa se tornar público. O novo portal reduz o custo de coordenação ao reunir validação, resultados da verificação, estado da análise, publicação, atualizações e uso em um só lugar. Ele não elimina o trabalho.

Prepare um pacote de plugin pronto para o diretório

O menor pacote confiável tem esta estrutura:

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

O manifesto precisa de um name permanente em letras minúsculas, um displayName voltado às pessoas, uma version, uma description útil, um autor e uma declaração de licença ou um arquivo de licença separado. Escolha o nome permanente com cuidado. É possível alterar displayName, mas o nome do manifesto é a identidade do plugin.

O README não é mera organização do repositório. O diretório o utiliza como conteúdo da página, e a validação bloqueia plugins cujo README tenha menos de 40 palavras fora de blocos de código. Explique o que o plugin faz, como usá-lo e quais dados ele envia. Nunca coloque credenciais reais no repositório.

Se o pacote fizer referência a um servidor remoto, informe o endpoint HTTPS em .mcp.json. Não inclua chaves de API nesse arquivo. Todo instalador recebe os arquivos do plugin.

Teste localmente e valide novamente no portal

A validação local encontra arquivos de plugin malformados antes mesmo de o GitHub entrar no processo:

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

O primeiro comando verifica a sintaxe e o schema dos arquivos. O segundo inicia uma sessão do Claude Code com a pasta de trabalho carregada, permitindo testar seus skills e comandos. A validação local não substitui o botão Validate do portal. O portal também verifica requisitos do diretório, estrutura do repositório, conflitos de nome, políticas de arquivos e outras regras de envio.

Neste passo a passo, foi criado um pequeno plugin chamado release-note-builder, com um skill e três arquivos de issues sintéticas: uma nova exportação de logs de auditoria em CSV, paginação aprimorada e correção de e-mails duplicados. O Claude Code 2.1.283 retornou Validation passed, código de saída 0, sem erros nem avisos.

Depois, a pasta foi carregada com claude --plugin-dir para uma execução de teste. Como esta máquina não tinha uma sessão autenticada do Claude, a solicitação parou em Not logged in · Please run /login antes da chamada ao modelo. Nenhuma nota de versão gerada foi observada. Esse limite é importante: a pasta pode ser validada localmente, mas testar o comportamento exige acesso autenticado ao modelo. Para um fluxo mais completo de testes de comportamento, consulte o guia sobre avaliações de plugins no Claude Code.

Preencha o envio do plugin

A documentação pública descreve o portal em seis etapas práticas.

1. Origem

Informe o repositório do GitHub como URL ou no formato owner/repo. Se o plugin estiver abaixo da raiz do repositório, adicione o caminho correspondente. Escolha uma branch ou tag para as versões futuras ou deixe o campo em branco para acompanhar a branch padrão. Depois, selecione Validate.

A validação lê um commit. Se você enviar uma correção, selecione Re-validate para que o relatório examine o novo commit.

2. Detalhes da publicação

O portal monta a página usando plugin.json e o README. Se o nome, a descrição ou a explicação estiverem errados, edite os arquivos no repositório e valide novamente. Essa disciplina é útil: a promessa pública e o pacote entregue permanecem na mesma versão.

3. Tratamento de dados

Informe se o plugin lê ou armazena dados pessoais, envia dados para algum destino além dos conectores declarados, retém dados ou é destinado a menores de 18 anos. Trate essas respostas como parte do contrato do produto, não como simples preenchimento de formulário.

4. Conformidade e contato

Forneça um e-mail que a Anthropic possa usar durante a análise e, depois, conclua as quatro declarações obrigatórias. O portal pode devolver uma versão com problemas identificados ou mudanças solicitadas, portanto use uma caixa de entrada que alguém realmente acompanhe.

5. Atualizações

Escolha entre o webhook padrão de push do GitHub e apenas verificações agendadas. As duas opções permitem que o diretório monitore a branch ou tag definida. Para configurar o webhook, é preciso ter acesso de administrador ao repositório.

6. Revisão e envio

Confirme os detalhes e selecione Submit for review. Uma organização pode criar até 10 envios em 24 horas, e rascunhos e envios retirados também entram nessa conta. Não crie duplicatas quando a intenção for continuar um rascunho existente.

Envie o servidor MCP remoto separadamente

Se o plugin chamar um servidor MCP remoto operado por você, volte a Submit new e escolha MCP connector. O caminho do conector solicita mais detalhes operacionais porque a Anthropic está publicando um serviço em funcionamento, não uma pasta.

Prepare a URL do servidor, as URLs da documentação e da política de privacidade, um ícone, credenciais de teste para o avaliador e imagens do carrossel de qualquer MCP App. O fluxo documentado cobre conexão, ferramentas sincronizadas, página pública, casos de uso, empresa, autenticação, tratamento de dados, instruções de teste, conformidade e análise final.

Os campos da página pública incluem um nome de servidor com até 100 caracteres, uma descrição de uma linha com até 200 caracteres, uma descrição mais longa com até 2,000 caracteres, de uma a cinco categorias, documentação, privacidade, suporte, ícone e um slug de URL permanente. Os avaliadores também precisam de uma conta de teste preenchida quando o produto exigir uma. Não afirme que um conector está pronto apenas porque o endpoint de integridade responde. Primeiro, execute todas as ferramentas no MCP Inspector ou como conector personalizado no Claude.

Leia o status como uma fila de ações

Não existe um prazo prometido para a análise. A pergunta útil não é “Quanto tempo leva a análise?”, mas “Quem precisa agir agora?”.

Approved não significa que o plugin pode ser instalado; Published, sim. A configuração padrão ainda pode exigir que um avaliador da Anthropic publique uma versão aprovada. Mais tarde, alguns plugins podem ser configurados para publicar automaticamente as atualizações aprovadas, mas uma versão retida continua aguardando.

Planeje as atualizações antes do primeiro lançamento

Depois da publicação, faça o merge na branch monitorada ou mova a tag monitorada. O diretório lê o novo commit, faz a validação e a varredura de segurança e o exibe como outra versão. Aumente a version em plugin.json a cada lançamento.

Uma atualização com falha ou retida não tira do ar a publicação que funciona. O diretório continua entregando a última versão publicada até que a substituta entre no ar. Isso transforma a branch em um feed de lançamentos, e não apenas em um local para armazenar o código-fonte.

A aba Usage fecha o ciclo de feedback. Ela pode exibir instalações, contas ativas, retenção, participação por versão, uso dos componentes, erros de carregamento, chamadas MCP e latência, visualizações da página, cliques de instalação e instalações no período selecionado de até 90 dias. Os números são atualizados uma vez por dia em UTC e podem ser exportados como CSV. Não prometa um número de instalações antes que o portal registre algum.

Os seis tipos de equipe que mais se beneficiam

1. Equipes SaaS com um produto MCP remoto

A equipe de produto envia o servidor em funcionamento como conector e cria um pacote de plugin com um skill de fluxo de trabalho. Os clientes recebem acesso às ferramentas e também as instruções que as tornam úteis. A equipe acompanha a integridade do servidor e o uso das ferramentas pelo conector, além das instalações e do uso dos componentes pelo plugin.

2. Empresas de software para fluxos de trabalho

Uma plataforma de despesas, recrutamento, suporte ou vendas pode transformar seu melhor procedimento operacional em um skill e combiná-lo com o conector do produto. O ganho está na qualidade da adoção: os usuários adicionam um fluxo de trabalho, não um conjunto de métodos de API sem explicação.

3. Mantenedores de plugins open source

O mantenedor pode manter o código público, acompanhar a branch de lançamento e usar o portal como canal estável de publicação e atualização. A última versão aprovada permanece disponível enquanto um novo commit é corrigido, o que reduz a pressão para que todo push no repositório esteja imediatamente pronto para os usuários.

4. Agências que entregam plugins a clientes

A agência pode desenvolver e testar a pasta, mas a organização do cliente deve fazer o envio quando o cliente precisar ser o proprietário da publicação. O resultado é uma transferência mais clara: controle do repositório, propriedade no diretório, contato de suporte e analytics ficam com o comprador, não com a empresa contratada.

5. Equipes de plataforma em grandes empresas

Um Owner do Enterprise pode conceder a permissão Directory a pessoas específicas sem compartilhar uma função ampla de proprietário. Assim, a equipe separa o trabalho de lançamento da administração geral da organização e mantém a publicação na organização da empresa.

6. Criadores de ferramentas para Claude Code que querem ir além do terminal

Um comando ou skill pode chegar ao diretório mais amplo, mas só depois de o desenvolvedor conferir a compatibilidade entre interfaces. Skills funcionam no chat, no Cowork e no Claude Code. Agentes e hooks não funcionam no chat, servidores MCP locais não funcionam no chat e servidores LSP continuam restritos ao Claude Code. O ganho é evitar uma publicação que prometa a mesma experiência em todos os lugares quando o pacote não consegue entregá-la.

Três produtos que vale a pena criar em torno do portal

1. Plugin Release Gate, a melhor oportunidade

Crie uma verificação do GitHub que examine o plugin antes que uma branch de lançamento chegue ao portal. Ela executaria a validação local, confirmaria o README e a licença, sinalizaria combinações de componentes sem suporte, compararia a versão do manifesto e produziria um relatório de prontidão para o diretório.

A demanda já é visível: claude code plugins recebe cerca de 5,400 buscas mensais nos EUA, com intenção comercial e CPC de $6.22. A menor versão vendável é um GitHub App acompanhado de um relatório web e um badge para o repositório. A ressalva é importante: o produto não pode prometer honestamente a aprovação no portal, porque as verificações do diretório e a análise humana da Anthropic vão além do comando local. Seu valor está em reduzir falhas evitáveis, não em garantir a aprovação.

2. Directory Listing Optimizer

Crie uma camada de relatórios que importe o CSV exportado pelo portal e transforme visualizações, cliques de instalação, instalações, fontes de descoberta, versões e uso dos componentes em recomendações para lançamentos e para a página pública. O comprador é quem publica plugins e já tem tráfego suficiente para tornar úteis os dados diários.

claude plugins recebe cerca de 8,100 buscas mensais nos EUA, tem intenção comercial e CPC de $9.05. Um MVP precisa de upload de CSV, cálculos de funil, comparação entre versões e uma lista semanal de ações. A ressalva é a partida a frio: antes da publicação e do uso real, o produto não tem dados proprietários para analisar. Além disso, ele depende de uma exportação, não de uma API documentada de analytics.

3. Cross-Surface Plugin Auditor

Crie um scanner estático que mostre exatamente o que Chat, Cowork e Claude Code carregarão de uma única pasta de plugin. Ele deve sinalizar um diretório bin/ no nível superior, pressupostos sobre MCP local, agentes e hooks ignorados pelo chat e LSPs exclusivos do Claude Code; depois, deve gerar uma matriz de testes.

claude-plugins marketplace recebe cerca de 1,900 buscas mensais nos EUA, com dificuldade 16 e intenção comercial. O MVP é um scanner de repositório baseado na tabela de compatibilidade da Anthropic. A ressalva é a manutenção: a compatibilidade da plataforma mudará, e desenvolvedores focados apenas no terminal talvez não se interessem por interfaces mais amplas.

O release gate é a melhor aposta porque participa de todas as versões, não apenas da primeira publicação. Além disso, complementa o portal em vez de tentar substituí-lo.

O que o portal não resolve

Ele não transforma um plugin fraco em algo útil. A validação pode comprovar que os arquivos estão bem-formados e seguem as políticas, mas não consegue provar que um skill melhora os resultados. Também não garante comportamento idêntico dos componentes em todos os aplicativos do Claude. E não oferece prazo fixo de análise, selo Verified sob demanda nem público de instalação no dia do lançamento.

O portal também não reúne um produto MCP hospedado em uma única publicação. O envio separado do conector é intencional, porque autenticação do servidor, integridade, ferramentas e políticas precisam de um registro operacional próprio.

A experiência unificada de descoberta ainda será liberada gradualmente nas semanas após o lançamento de 25 de setembro. Publique para as interfaces que já estão documentadas e trate a descoberta mais ampla como uma distribuição futura, não como um alcance atual que você possa prometer.

O que fazer na segunda-feira

Escolha a organização do Claude que deverá ser proprietária da publicação. Coloque um fluxo de trabalho real em um pacote de plugin, defina um nome estável no manifesto, escreva um README útil, adicione uma licença e execute a validação local. Se o pacote chamar seu servidor MCP hospedado, prepare o envio do conector em paralelo. Não abra o portal antes de definir a propriedade e o caminho final do repositório.

Se você quer transformar um plugin e seu conector de produção em um único sistema de lançamento confiável, conheça os sistemas de IA em produção.