Server MCP Claude e plugin: come pubblicarli nella directory

In breve: come pubblicare plugin e server MCP Claude

Per pubblicare un plugin Claude, segui questa sequenza:

1. Verifica che l'account Claude usato per l'invio abbia un piano Pro, Max, Team o Enterprise.
2. Scegli l'organizzazione che dovrà conservare la proprietà della scheda nel tempo.
3. Prepara il plugin con .claude-plugin/plugin.json, un README e una licenza.
4. Testa la cartella in locale, poi inseriscila in un repository GitHub sul quale l'account GitHub collegato abbia permessi di push.
5. Apri il portale per sviluppatori, scegli Plugin bundle, indica repository, eventuale percorso del plugin e branch o tag monitorato, quindi esegui Validate.
6. Completa le sezioni su trattamento dei dati, conformità, contatti e aggiornamenti, poi seleziona Submit for review.
7. Se il plugin rimanda a un server MCP remoto gestito da te, crea per quel server un invio distinto di tipo MCP connector.

Il repository può restare privato durante la validazione e la review, purché siano rispettate le condizioni di Anthropic per l'accesso a GitHub e il caricamento del codice sorgente. Prima che il plugin venga pubblicato, però, deve diventare pubblico.

Scegli la scheda giusta prima di aprire il portale

Plugin e connettore sono collegati, ma non sono intercambiabili. Pensa al plugin come a un manuale operativo confezionato e al server MCP remoto come al servizio attivo che lo rende utile: il primo insegna a Claude il workflow, il secondo gli offre accesso in tempo reale al prodotto o ai dati.

Una skill non rappresenta un terzo tipo di invio: va inserita in un plugin bundle. Se il bundle richiama il tuo server MCP in hosting, invia entrambi i prodotti dalla stessa organizzazione Claude e associa a tutti e due lo stesso URL del server. In questo modo il portale può abbinare le schede ed evitare che gli utenti vedano set di tool duplicati.

Stabilisci chi sarà proprietario della scheda

La scelta dell'organizzazione è una decisione di prodotto destinata a durare, non un dettaglio amministrativo. Per un plugin bundle, la scheda appartiene alla prima organizzazione che invia quella cartella del repository. Una seconda organizzazione non può inviare la stessa combinazione di repository e cartella.

Le regole per gli account sono semplici:

• Con Pro o Max, l'invio parte dal proprio account.
• Con Team o Enterprise, può procedere un Owner.
• Con Enterprise, un Owner può assegnare il permesso Directory tramite un ruolo personalizzato.
• L'account GitHub collegato nell'organizzazione Claude deve poter effettuare push sul repository.

Se il plugin viene sviluppato da un'agenzia ma la sua identità pubblica deve appartenere al cliente, l'invio dovrebbe partire dall'organizzazione del cliente. Trasferire il repository in un secondo momento non equivale a trasferire la scheda nella directory.

Quanto costa questo percorso

Le istruzioni pubbliche di Anthropic non indicano una tariffa separata per la pubblicazione nella directory, ma un account Free non può effettuare invii. Il costo minimo effettivo coincide quindi con il piano a pagamento necessario per accedere alla procedura.

• Chi sviluppa da solo e non ha ancora un piano a pagamento può scegliere Pro a $20 per un mese con fatturazione mensile, oppure a $17 al mese pagando $200 in anticipo per un anno.
• Team parte da due persone. Due licenze Standard costano $50 per un mese con fatturazione mensile, oppure $40 al mese con fatturazione annuale.
• Max parte da $100 al mese, ma non è necessario scegliere Max soltanto per effettuare l'invio.

Il costo maggiore resta il lavoro di rilascio. Un prodotto in hosting richiede due invii completi: uno per il bundle e uno per il connettore. Il plugin deve inoltre avere un manifest stabile, un README di almeno 40 parole, una licenza, risposte sul trattamento dei dati, un contatto per la review e un repository che possa diventare pubblico. Il nuovo portale riduce il costo di coordinamento riunendo validazione, risultati delle scansioni, stato della review, pubblicazione, aggiornamenti e dati di utilizzo. Il lavoro, però, rimane.

Prepara un plugin bundle adatto alla directory

Il bundle minimo realmente presentabile ha questa struttura:

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

Il manifest richiede un name permanente in minuscolo, un displayName leggibile, una version, una description utile, l'autore e la dichiarazione della licenza oppure un file di licenza separato. Scegli con attenzione il nome permanente: displayName può cambiare, mentre il nome nel manifest costituisce l'identità del plugin.

Il README non è semplice manutenzione del repository. La directory lo usa come contenuto della scheda e la validazione blocca i plugin il cui README contiene meno di 40 parole al di fuori del codice. Spiega cosa fa il plugin, come si usa e quali dati invia. Non inserire mai credenziali reali nel repository.

Se il bundle richiama un server remoto, indica l'endpoint HTTPS in .mcp.json. Non aggiungere chiavi API: chiunque installi il plugin riceverà quei file.

Esegui i test in locale, poi valida di nuovo nel portale

La validazione locale intercetta file del plugin non validi prima ancora di coinvolgere GitHub:

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

Il primo comando verifica sintassi e schema dei file. Il secondo avvia una sessione di Claude Code caricando la cartella di lavoro, così puoi provare skill e comandi. La validazione locale non sostituisce il pulsante Validate del portale, che controlla anche i requisiti della directory, la struttura del repository, eventuali conflitti di nome, le regole sui file e gli altri vincoli di invio.

Per questa prova è stato creato un piccolo plugin release-note-builder, composto da una skill e tre file di issue sintetici: una nuova esportazione CSV dell'audit log, una paginazione migliorata e la correzione delle email duplicate. Claude Code 2.1.283 ha restituito Validation passed, codice di uscita 0, senza errori né avvisi.

La cartella è stata poi caricata con claude --plugin-dir per eseguire un test sui dati predisposti. Su questa macchina non era presente una sessione Claude autenticata, quindi la richiesta si è fermata su Not logged in · Please run /login prima di chiamare un modello. Non è stata osservata alcuna nota di rilascio generata. È una distinzione importante: la cartella può essere validata in locale, ma per verificare il comportamento serve l'accesso autenticato a un modello. Per una procedura di test più completa, consulta la guida dedicata agli eval dei plugin Claude Code.

Compila l'invio del plugin

La documentazione pubblica suddivide il percorso nel portale in sei fasi operative.

1. Source

Inserisci il repository GitHub come URL oppure nel formato owner/repo. Se il plugin si trova sotto la radice del repository, aggiungi il relativo percorso. Scegli un branch o un tag da seguire per le versioni future; in alternativa, lascia il campo vuoto per usare il branch predefinito. Poi seleziona Validate.

La validazione legge un solo commit. Se invii una correzione con push, seleziona Re-validate affinché il report analizzi il nuovo commit.

2. Listing details

Il portale costruisce la scheda usando plugin.json e il README. Se nome, descrizione o spiegazione non sono corretti, modifica i file nel repository ed esegui di nuovo la validazione. È una buona disciplina: la promessa pubblica e il pacchetto distribuito restano allineati nello stesso rilascio.

3. Data handling

Indica se il plugin legge o conserva dati personali, invia dati al di fuori dei connettori dichiarati, mantiene dati nel tempo o è destinato a persone con meno di 18 anni. Queste risposte fanno parte del contratto del prodotto: non sono semplici campi da riempire.

4. Compliance and contact

Fornisci un indirizzo email che Anthropic possa usare durante la review, poi completa le quattro dichiarazioni obbligatorie. Il portale può restituire una versione segnalando problemi o modifiche richieste: usa quindi una casella che qualcuno controlli davvero.

5. Updates

Scegli tra il webhook GitHub predefinito per i push e i soli controlli programmati. Entrambe le opzioni consentono alla directory di monitorare il branch o il tag selezionato. Per configurare il webhook servono permessi amministrativi sul repository.

6. Review and submit

Controlla i dati e seleziona Submit for review. Un'organizzazione può creare fino a 10 invii nell'arco di 24 ore; nel conteggio rientrano anche le bozze e gli invii ritirati. Non creare duplicati quando vuoi semplicemente proseguire una bozza esistente.

Come pubblicare separatamente un server MCP Claude remoto

Se il plugin chiama un server MCP remoto gestito da te, torna su Submit new e scegli MCP connector. Questo percorso richiede più dettagli operativi perché Anthropic sta inserendo in directory un servizio attivo, non una cartella.

Prepara l'URL del server, gli URL della documentazione e dell'informativa sulla privacy, un'icona, le credenziali di test per i reviewer e le eventuali immagini del carosello MCP App. Il flusso documentato copre connessione, tool sincronizzati, scheda pubblica, casi d'uso, azienda, autenticazione, trattamento dei dati, istruzioni di test, conformità e review finale.

I campi della scheda pubblica comprendono un nome del server fino a 100 caratteri, una descrizione su una riga fino a 200 caratteri, una descrizione estesa fino a 2,000 caratteri, da una a cinque categorie, documentazione, privacy, assistenza, icona e uno slug URL permanente. Se il prodotto lo richiede, i reviewer devono anche disporre di un account di test già configurato. La risposta corretta dell'endpoint di stato non basta per dichiarare pronto un connettore: prima prova ogni tool con MCP Inspector o come connettore personalizzato in Claude.

Interpreta lo stato come una coda di azioni

Non esiste una durata garantita per la review. La domanda utile non è «Quanto dura la review?», ma «A chi tocca agire?».

Approved non significa installabile; Published sì. Con l'impostazione predefinita potrebbe comunque essere necessario che un reviewer Anthropic pubblichi una versione approvata. In seguito, alcuni plugin possono essere configurati per pubblicare automaticamente gli aggiornamenti che superano i controlli, ma una versione trattenuta resta in attesa.

Pianifica gli aggiornamenti prima del lancio

Dopo la pubblicazione, esegui il merge nel branch monitorato oppure sposta il tag seguito. La directory legge il nuovo commit, lo valida, lo sottopone alla scansione di sicurezza e lo mostra come una nuova versione. Aumenta il valore version in plugin.json a ogni rilascio.

Un aggiornamento non riuscito o trattenuto non rimuove la scheda funzionante. La directory continua a distribuire l'ultima versione pubblicata finché quella sostitutiva non va online. Il branch diventa così un feed di rilascio, non soltanto un archivio del codice sorgente.

La scheda Usage chiude il ciclo di feedback. Può mostrare installazioni, account attivi, retention, quota per versione, utilizzo dei componenti, errori di caricamento, chiamate MCP e latenza, visualizzazioni della scheda, clic di installazione e installazioni per un periodo selezionato fino a 90 giorni. I dati vengono aggiornati una volta al giorno in UTC e possono essere esportati in CSV. Non promettere un numero di installazioni prima che il portale ne abbia registrata una.

I sei tipi di team che ne traggono più vantaggio

1. Team SaaS con un prodotto MCP remoto

Il team di prodotto invia il server attivo come connettore e gli affianca, sotto forma di plugin, una skill che ne descrive il workflow. I clienti ottengono sia l'accesso ai tool sia le istruzioni che li rendono utili. Il team ricava dal connettore dati sullo stato del server e sull'uso dei tool, quindi dal plugin le metriche di installazione e utilizzo dei componenti.

2. Aziende di software per workflow

Una piattaforma per spese, recruiting, assistenza o vendite può trasformare la propria procedura operativa migliore in una skill e abbinarla al connettore del prodotto. Il vantaggio sta nella qualità dell'adozione: gli utenti aggiungono un workflow, non un insieme di metodi API privi di spiegazione.

3. Maintainer di plugin open source

Un maintainer può lasciare pubblico il codice, monitorare il branch di rilascio e usare il portale come scheda stabile e canale di aggiornamento. L'ultima versione che ha superato i controlli resta disponibile mentre viene corretto un nuovo commit, riducendo la pressione di rendere ogni push sul repository immediatamente pronto per gli utenti.

4. Agenzie che realizzano plugin per i clienti

Un'agenzia può sviluppare e testare la cartella, ma se la scheda deve appartenere al cliente è opportuno che sia l'organizzazione del cliente a inviarla. Il passaggio di consegne risulta più ordinato: controllo del repository, proprietà nella directory, contatto per l'assistenza e analytics rimangono all'acquirente anziché al fornitore.

5. Team responsabili di piattaforme Enterprise

Un Enterprise Owner può assegnare il permesso Directory ai membri selezionati, senza condividere un ruolo Owner più ampio. Il team separa così il lavoro di rilascio dall'amministrazione generale dell'organizzazione, mantenendo la scheda nell'organizzazione aziendale.

6. Sviluppatori di tool Claude Code che vogliono andare oltre il terminale

Un comando o una skill può arrivare nella directory più ampia, ma solo dopo aver verificato quali ambienti supporta. Le skill funzionano in chat, Cowork e Claude Code. Agenti e hook non funzionano in chat; lo stesso vale per i server MCP locali, mentre i server LSP restano esclusivi di Claude Code. Il vantaggio è evitare una scheda che prometta la stessa esperienza ovunque quando il pacchetto non può offrirla.

Tre prodotti da costruire intorno al portale

1. Plugin Release Gate, l'opportunità più solida

Crea un controllo GitHub che esamini il plugin prima che un branch di rilascio raggiunga il portale. Dovrebbe eseguire la validazione locale, verificare README e licenza, segnalare combinazioni di componenti non supportate, confrontare la versione del manifest e produrre un report sull'idoneità alla directory.

La domanda è già visibile: claude code plugins riceve circa 5,400 ricerche mensili negli Stati Uniti, con intento commerciale e CPC di $6.22. La versione minima vendibile consiste in una GitHub App, un report web e un badge per il repository. C'è però un limite importante: non può promettere onestamente l'approvazione nel portale, perché i controlli della directory e la review umana di Anthropic vanno oltre il comando locale. Il suo valore è ridurre gli errori evitabili, non garantire l'accettazione.

2. Directory Listing Optimizer

Crea un livello di reporting che importi l'esportazione CSV del portale e trasformi visualizzazioni, clic di installazione, installazioni, origini della scoperta, versioni e utilizzo dei componenti in suggerimenti per i rilasci e la scheda. Il cliente ideale è un publisher di plugin con traffico sufficiente a rendere utili i dati giornalieri.

claude plugins riceve circa 8,100 ricerche mensili negli Stati Uniti, ha intento commerciale e un CPC di $9.05. Un MVP richiede caricamento del CSV, calcolo del funnel, confronto fra versioni e un elenco settimanale di azioni. Il limite è la partenza a freddo: prima della pubblicazione e dell'utilizzo reale, il prodotto non ha dati proprietari da analizzare. Inoltre dipende da un'esportazione, non da un'API documentata per gli analytics.

3. Cross-Surface Plugin Auditor

Crea uno scanner statico che mostri con precisione cosa caricheranno Chat, Cowork e Claude Code da una singola cartella plugin. Dovrebbe segnalare una directory bin/ al livello principale, le dipendenze da MCP locali, agenti e hook ignorati dalla chat e gli LSP esclusivi di Claude Code, quindi generare una matrice di test.

claude-plugins marketplace riceve circa 1,900 ricerche mensili negli Stati Uniti, con difficoltà 16 e intento commerciale. L'MVP è uno scanner di repository basato sulla tabella di compatibilità di Anthropic. Il limite è la manutenzione: il supporto della piattaforma cambierà e chi sviluppa esclusivamente per il terminale potrebbe non essere interessato alla compatibilità più ampia.

Il release gate è la scommessa migliore perché interviene su ogni versione, non soltanto sulla prima scheda. Inoltre completa il portale invece di tentare di sostituirlo.

Cosa non risolve questo portale

Il portale non rende utile un plugin debole. La validazione può dimostrare che i file sono ben formati e compatibili con le policy, ma non che una skill migliori i risultati. Non garantisce che i componenti si comportino allo stesso modo in ogni app Claude. Non offre tempi fissi per la review, un'etichetta Verified su richiesta o un pubblico già pronto a installare il prodotto il giorno del lancio.

Inoltre non riunisce un prodotto MCP in hosting in un'unica scheda. L'invio separato del connettore è intenzionale: autenticazione del server, stato, tool e policy richiedono un proprio registro operativo.

L'esperienza unificata di scoperta è ancora in fase di distribuzione nelle settimane successive al lancio del 25 settembre. Pubblica pensando agli ambienti già documentati e considera la scoperta più ampia come una distribuzione in arrivo, non come una portata attuale da promettere.

Cosa fare lunedì

Scegli l'organizzazione Claude che dovrà possedere la scheda. Inserisci un workflow reale in un plugin bundle, assegna al manifest un nome stabile, aggiungi un README utile e una licenza, quindi esegui la validazione locale. Se il plugin chiama il tuo server MCP in hosting, prepara in parallelo l'invio del connettore. Non aprire il portale finché la proprietà e il percorso nel repository non sono definitivi.

Se vuoi sviluppare un plugin e il relativo connettore di produzione come un unico sistema di rilascio affidabile, scopri i sistemi di produzione IA.