Submit a Claude plugin to the directory

Pro and Max subscribers can submit from their own account. Team and Enterprise require an Owner; Enterprise can also delegate the Directory permission through a custom role. Free accounts cannot submit. No partner-program application is required first.

Choose the Claude organization that should own the listing. If you operate the remote MCP server referenced by your plugin, submit that server separately as a connector as well. A skills-only package uses the plugin-bundle route.

Check eligibility and the two submission types.

A plugin packages reusable capabilities together. Skills describe workflows; an MCP connection exposes tools or data. A plugin can contain either or both. Claude Code also supports components such as LSP integrations, commands, hooks and agents. Do not assume every component runs on every Claude surface.

The manifest belongs at .claude-plugin/plugin.json. Put component folders alongside .claude-plugin/, rather than inside it. The package can include skills/, .mcp.json, a README and a license. A remote MCP reference still needs the user to connect it in chat or Cowork; Claude Code connects directly.

Test on the surfaces you support. Agents and hooks load in Cowork and Claude Code, while chat ignores them. A local MCP process does not run in chat. See the structure and testing reference before promising cross-app behavior.

Use the official pre-submission checklist as the detailed specification:

• Include the manifest, a README with at least 40 non-code words, and a LICENSE file or manifest license value.
• Keep required runtime files inside the plugin folder and use the expected component names.
• Choose a distinct identity; avoid implying that your third-party package is official.
• Fix every blocking finding. A policy hold needs reviewer attention; it is not itself a rejection.

The optional local validator catches file-format and schema problems. It does not replace the portal’s directory checks. The command below is documentation-based and was not executed for this guide.

claude plugin validate ./your-plugin

Connect a GitHub account with push access in the Claude organization you are using. The repository may remain private during review, but must be public to publish. Private review requires the documented source-upload consent and GitHub App access.

1. Open the developer portal, select Submit new, then Plugin bundle.
2. Supply the repository, plugin folder if needed, and tracked branch or tag. Validate that commit; fix blockers and validate again after changes.
3. Check listing details derived from the manifest and README.
4. Answer the data-handling questions and verify the compliance contact and acknowledgements.
5. Review the update-delivery choice and select Submit for review.

Follow the official steps for exact fields. A local ZIP upload for personal testing is not a directory submission.

The status reference distinguishes the next actor:

• Draft: you still need to submit.
• Scanning: automated checks are pending or running.
• Needs changes: read the finding and repair the package.
• In review: Anthropic is reviewing it.
• Approved: checks passed, but this does not mean the plugin is live.
• Published: a version is available in the directory.

Read the status card to see who publishes next. Under the default setting, selecting Publish requests publication by an Anthropic reviewer; other reviewer-applied settings allow different first-release and auto-publish behavior. Check your actual setting rather than assuming approval publishes automatically. Publishing settings.

Review duration is not fixed. This guide has no measured approval rate or promised turnaround.

The official published-plugin documentation describes a Usage tab with a selectable window of up to 90 days and CSV export:

• Reach: installs, active accounts and retention; installation breakdowns include surface and discovery origin.
• Versions: account distribution across releases.
• Components: usage of skills, commands, agents, hooks and MCP servers.
• Quality: loading failures, plus MCP call errors and latency.
• Directory funnel: listing views, installation clicks and installs.

Figures update daily in UTC. Check the data-through date. Before real activity exists, Preview displays sample numbers—not your actual adoption.

The launch announcement also describes searches that lead people to listings. We have not inspected a live publisher dashboard or verified a search-query report in an account. No actual installation totals, revenue, search volume or analytics results are claimed here.

Validation passes but submission fails: verify GitHub push access in the current Claude organization. Public-repository validation can succeed before that access check.

Approval is visible but users cannot install: follow the publication actor shown on the status card; Approved and Published are different states.

A component is missing: compare its support on the target app before treating it as a broken package.

A new version is not live: the existing published version can remain available while a replacement fails checks or awaits review. Track both versions separately. Update behavior.

Anthropic’s security-scan guidance covers undisclosed data transfers, hidden execution and permission-setting changes. Document what runs and which services receive data; readable source helps reviewers inspect behavior. Disclosure does not make otherwise prohibited behavior acceptable.

Keep real credentials out of source and examples. Review the official credential-handling rules before configuring a connector. As an additional practical check, use our MCP server security checklist to inspect access and write boundaries before your own test. A directory review is not evidence that we tested your plugin.