How to Publish Claude Plugins

The short answer

To publish a Claude plugin, use this sequence:

1. Confirm that the submitting Claude account is on Pro, Max, Team, or Enterprise.
2. Choose the organization that should own the listing for the long term.
3. Package the plugin with .claude-plugin/plugin.json, a README, and a license.
4. Test the folder locally, then put it in a GitHub repository your connected GitHub account can push to.
5. Open the developer portal, choose Plugin bundle, enter the repository, optional plugin path, and tracked branch or tag, then run Validate.
6. Complete the data handling, compliance, contact, and update settings, then select Submit for review.
7. If the plugin points to a remote MCP server you run, create a separate MCP connector submission for that server.

The repository may stay private during validation and review if you satisfy Anthropic's GitHub access and source-upload conditions. It must be public before the plugin goes live.

Choose the listing before you touch the portal

A plugin and a connector are related, but they are not interchangeable. Think of the plugin as a boxed operating manual and the remote MCP server as the staffed service desk behind it. One teaches Claude the workflow. The other gives Claude live access to your product or data.

A skill is not a third submission type. Put it inside a plugin bundle. If that bundle references your hosted MCP server, submit both products from the same Claude organization and point them at the same server URL. That lets the portal pair the listings and keeps users from seeing duplicate tool sets.

Decide who owns the listing

The organization choice is a durable product decision, not an admin detail. For a plugin bundle, the first organization to submit a repository folder holds that listing. A second organization cannot submit the same repository and folder.

The account rules are simple:

• On Pro or Max, you submit from your own account.
• On Team or Enterprise, an Owner can submit.
• On Enterprise, an Owner can grant the Directory permission through a custom role.
• The GitHub account connected inside that Claude organization must be able to push to the repository.

If an agency builds the plugin but the client should own its public identity, the client's organization should submit it. Handing over a repository later is not the same as handing over the directory listing.

What the route costs

Anthropic's public instructions do not state a separate directory listing fee, but a Free account cannot submit. The cash floor is therefore the paid account required to open the door.

• A solo builder starting from no paid account can use Pro at $20 for one monthly-billed month, or $17 per month with $200 billed up front for a year.
• Team starts at two people. Two standard seats cost $50 for a monthly-billed month, or $40 per month on annual billing.
• Max starts at $100 per month, but Max is not required just to submit.

The larger cost is release work. A hosted product needs two prepared submissions, one for the bundle and one for the connector. A plugin also needs a stable manifest, a 40-word minimum README, a license, data-handling answers, a review contact, and a repository that can become public. The new portal reduces the coordination tax by keeping validation, scan findings, review state, publication, updates, and usage in one place. It does not remove the work.

Prepare a directory-ready plugin bundle

The smallest credible bundle has this shape:

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

The manifest needs a permanent lowercase name, a human-facing displayName, a version, a useful description, an author, and a license declaration or separate license file. Choose the permanent name carefully. You can change displayName, but the manifest name is the plugin's identity.

The README is not repository housekeeping. The directory uses it as listing material, and validation blocks a plugin whose README has fewer than 40 non-code words. Say what the plugin does, how someone uses it, and what data it sends. Keep every real credential out of the repository.

If the bundle references a remote server, put the HTTPS endpoint in .mcp.json. Do not put API keys there. Every installer receives the plugin files.

Test locally, then validate again in the portal

Local validation catches malformed plugin files before GitHub is involved:

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

The first command checks file syntax and schema. The second starts one Claude Code session with the working folder loaded, so you can exercise its skills and commands. Local validation is not a substitute for the portal's Validate button. The portal also checks directory requirements, repository layout, naming conflicts, file policy, and other submission rules.

For this walkthrough, a small release-note-builder plugin was created with one skill and three synthetic issue files: a new audit-log CSV export, improved pagination, and a duplicate-email fix. Claude Code 2.1.283 returned Validation passed, exit code 0, with no errors or warnings.

The folder was then loaded with claude --plugin-dir for a fixture run. This machine had no authenticated Claude session, so the request stopped with Not logged in · Please run /login before a model call. No generated release note was observed. That boundary matters: folder validation can run locally, but a behavior check needs authenticated model access. For a fuller behavior-testing workflow, use the separate guide to Claude Code plugin evals.

Fill in the plugin submission

The public documentation describes the portal in six practical stages.

1. Source

Enter the GitHub repository as a URL or owner/repo. Add the plugin path if the plugin lives below the repository root. Choose a branch or tag for future versions, or leave it blank to follow the default branch. Then select Validate.

Validation reads one commit. If you push a fix, select Re-validate so the report reads the new commit.

2. Listing details

The portal builds the listing from plugin.json and the README. If the name, description, or explanation is wrong, edit the repository files and validate again. This is useful discipline: the public promise and the shipped package stay in the same release.

3. Data handling

Answer whether the plugin reads or stores personal data, sends data anywhere beyond its declared connectors, retains data, or is intended for people under 18. Treat these answers as part of the product contract, not form filler.

4. Compliance and contact

Provide an email that Anthropic can use for the review, then complete the four required acknowledgements. The portal can send a version back with findings or requested changes, so use an inbox someone actually monitors.

5. Updates

Choose the default GitHub push webhook or scheduled checks only. Both routes let the directory watch the tracked branch or tag. The webhook requires repository admin access to set up.

6. Review and submit

Confirm the details and select Submit for review. An organization may create up to 10 submissions in 24 hours, and drafts and withdrawn submissions count. Do not create duplicates when you mean to continue an existing draft.

Submit the remote MCP server separately

If your plugin calls a remote MCP server you operate, return to Submit new and choose MCP connector. The connector path asks for more operational detail because Anthropic is listing a live service, not a folder.

Prepare the server URL, documentation and privacy policy URLs, an icon, reviewer test credentials, and any MCP App carousel images. The documented flow covers the connection, synced tools, public listing, use cases, company, authentication, data handling, test instructions, compliance, and final review.

The public listing fields include a server name up to 100 characters, a one-line description up to 200 characters, a longer description up to 2,000 characters, one to five categories, documentation, privacy, support, icon, and a permanent URL slug. Reviewers also need a populated test account where the product requires one. Do not claim a connector is ready because its health endpoint answers. Run every tool through MCP Inspector or as a custom connector in Claude first.

Read the status as an action queue

There is no promised review duration. The useful question is not “How long does review take?” but “Who acts next?”

Approved does not mean installable. Published does. The default setting may still require an Anthropic reviewer to publish a passing version. Some plugins can later be configured so passing updates publish automatically, but a held version still waits.

Plan updates before the first launch

After publication, merge to the tracked branch or move the tracked tag. The directory reads the new commit, validates it, security-scans it, and shows it as another version. Raise the version in plugin.json on each release.

A failed or held update does not take the working listing down. The directory continues serving the last published version until the replacement goes live. That makes the branch a release feed, not just source storage.

The Usage tab then closes the feedback loop. It can show installs, active accounts, retention, version share, component use, load errors, MCP calls and latency, listing views, install clicks, and installs for a selected period up to 90 days. The figures update once a day in UTC and can be exported as CSV. Do not promise an install number before the portal has recorded one.

The six teams that benefit most

1. SaaS teams with a remote MCP product

The product team submits the live server as a connector and packages a workflow skill around it as a plugin. Customers get tool access plus the instructions that make the tool useful. The team gets server health and tool usage from the connector, then install and component usage from the plugin.

2. Workflow software companies

An expense, recruiting, support, or sales platform can turn its best operating procedure into a skill and pair it with the product connector. The payoff is adoption quality: users add a workflow, not a bag of unexplained API methods.

3. Open-source plugin maintainers

A maintainer can keep the code public, track the release branch, and use the portal as the stable listing and update channel. The last passing version remains available while a new commit is fixed, which reduces pressure to make every repository push immediately user-ready.

4. Agencies shipping plugins for clients

An agency can build and test the folder, but the client organization should submit when the client must own the listing. The payoff is a cleaner handoff: repository control, directory ownership, support contact, and analytics land with the buyer rather than the contractor.

5. Enterprise platform teams

An Enterprise Owner can give selected members the Directory permission instead of sharing a broad owner role. The team can separate release work from general organization administration while keeping the listing in the company organization.

6. Claude Code tool builders expanding beyond the terminal

A command or skill can move into the wider directory, but only after the builder checks surface support. Skills work across chat, Cowork, and Claude Code. Agents and hooks do not run in chat, local MCP servers do not run in chat, and LSP servers remain Claude Code-only. The payoff is avoiding a listing that promises the same experience everywhere when the package cannot provide it.

Three products worth building around the portal

1. Plugin Release Gate, the strongest opportunity

Build a GitHub check that inspects a plugin before a release branch reaches the portal. It would run local validation, confirm the README and license, flag unsupported component combinations, compare the manifest version, and produce a directory-readiness report.

Demand is already visible: claude code plugins receives about 5,400 US searches a month, with commercial intent and a $6.22 CPC. The smallest sellable version is a GitHub App plus a web report and a repository badge. The catch is important: it cannot honestly promise portal approval because Anthropic's directory checks and human review extend beyond the local command. Its value is fewer preventable failures, not guaranteed acceptance.

2. Directory Listing Optimizer

Build a reporting layer that imports the portal's CSV export and turns views, install clicks, installs, discovery sources, versions, and component usage into release and listing recommendations. The buyer is a plugin publisher with enough traffic to make daily data useful.

claude plugins receives about 8,100 US searches a month, carries commercial intent, and has a $9.05 CPC. An MVP needs CSV upload, funnel calculations, version comparison, and a weekly action list. The catch is cold start: before publication and real usage, the product has nothing proprietary to analyze. It also depends on an export rather than a documented analytics API.

3. Cross-Surface Plugin Auditor

Build a static scanner that tells a team exactly what Chat, Cowork, and Claude Code will load from one plugin folder. It should flag a top-level bin/ directory, local MCP assumptions, chat-ignored agents and hooks, and Claude Code-only LSPs, then generate a test matrix.

claude-plugins marketplace receives about 1,900 US searches a month with difficulty 16 and commercial intent. The MVP is a repository scanner backed by Anthropic's support table. The catch is maintenance: platform support will change, and terminal-only builders may not care about wider compatibility.

The release gate is the best bet because it sits on every version, not only the first listing. It also complements the portal instead of trying to replace it.

What this portal does not solve

It does not make a weak plugin useful. Validation can prove that files are well formed and policy-compatible, but it cannot prove that a skill improves results. It does not guarantee identical component behavior in every Claude app. It does not provide a fixed review time, a Verified label on request, or an install audience on launch day.

It also does not collapse a hosted MCP product into one listing. The separate connector submission is deliberate because server authentication, health, tools, and policy need their own operational record.

The unified discovery experience is still rolling out over the weeks after the September 25 launch. Publish for the surfaces that are documented now, and treat wider discovery as arriving distribution, not current reach you can promise.

What to do Monday

Pick the Claude organization that should own the listing. Put one real workflow into a plugin bundle, give it a stable manifest name, a useful README, and a license, then run local validation. If it calls your hosted MCP server, prepare the connector submission in parallel. Do not open the portal until the ownership decision and repository path are final.

If you want a plugin and its production connector built as one reliable release system, see AI production systems.