AIREITERIf you are looking for the Claude plugin submission portal, use Anthropic’s developer portal at claude.ai/directory/manage. The current path is Submit new → Plugin bundle, but a public GitHub repository, an eligible plan and role, and a passing review are all part of getting a listing live.
The current Claude plugin submission route
The official route starts in Anthropic’s plugin submission documentation, not in the public GitHub marketplace repository. Each plugin folder is submitted separately, even when several plugins live in one repository.
| What you need | Current requirement |
|---|---|
| Submission page | claude.ai/directory/manage |
| Submission type | Plugin bundle |
| Source | A public GitHub repository before the listing goes live |
| Access | A plan and role allowed to submit to the directory |
| Review | Validation and security scanning; some versions are held for a reviewer |
| Publishing | A passing version still needs to be published |
This guide covers public directory distribution, not private team sharing or a local plugin install.
Before opening the portal
Prepare the repository before opening the portal.
1. Put the plugin in GitHub
The directory reads plugins from github.com, and Anthropic says the repository must be public before the listing goes live. If the plugin is below the repository root, note its folder path.
A standard Claude Code plugin commonly includes:
plugin-name/
├── .claude-plugin/
│ └── plugin.json
├── .mcp.json # optional
├── commands/ # optional
├── agents/ # optional
├── skills/ # optional
└── README.mdThe manifest and README supply much of the directory listing information. Check the plugin’s license and external services before submitting.
2. Run local validation
From the directory containing the plugin folder, run:
claude plugin validate ./<plugin-folder>This catches structure and formatting problems, but the portal’s Validate step runs additional checks. Treat the local command as a first pass, not as approval.
3. Separate an MCP connector when necessary
If your plugin references a remote MCP server that you operate and it has not already been submitted, Anthropic’s guide says to submit the server separately as an MCP connector. The plugin bundle and connector are different directory listings.
Submit one plugin bundle, step by step
1. Choose Plugin bundle
Open the developer portal and select Submit new. When asked what you want to submit, choose Plugin bundle. Choose MCP connector only when submitting a remote MCP server as its own listing.
2. Enter the repository, path, and branch
On Source, provide:
- The GitHub URL or
owner/repo. - Plugin path, if
.claude-plugin/plugin.jsonis not at the repository root. - Branch or tag, if the directory should track something other than the default branch.
A tag stays on its commit until you change the tag. If the branch name contains a slash, enter it explicitly or use the owner/repo@branch form described in the official submission guide.
Select Validate. If a finding blocks submission, fix the repository, push the change, and validate again. A validation result applies to one commit.
3. Check the generated listing
The Listing details step shows how the plugin will appear in the directory. Anthropic reads these details from plugin.json and the README.
Change the source files when you need to fix the name or short description. Anthropic’s official plugin directory also warns that a published installation slug should remain stable because users can encounter plugin-not-found. Use a display label for ordinary wording changes; reserve a rename mapping for a necessary migration.
4. Answer data-handling questions
The Data handling step asks whether the plugin:
- Reads or stores personal data.
- Sends data to services other than declared connectors.
- Retains data, and for how long.
- Targets people under 18.
Answer from the implementation. Include remote services, file access, telemetry, and retention behavior.
5. Complete compliance acknowledgements
On Compliance, confirm a contact email where Anthropic can reach you and select the required acknowledgements. The plugin must comply with Anthropic’s Software Directory policy.
6. Submit and choose update delivery
On Review and submit, confirm the details and choose how new versions arrive:
- GitHub push webhook, selected by default in the current guide; it can trigger checks after pushes when configured.
- Scheduled check only, which relies on checks of the tracked branch or tag.
Select Submit for review. GitHub administrator access is required to configure the webhook. Anthropic currently limits an organization to 10 submissions in any 24-hour period, and saved drafts and withdrawn submissions count toward that limit. These limits and update settings are documented in the submission workflow.
What happens after submission
Anthropic scans the newest commit on the tracked branch or tag, reruns directory validation, and performs a security scan. The official guide describes the following states:
| Status | What it means | Next action |
|---|---|---|
| Passes every check | The version is eligible to publish | Select Publish |
| Held for a reviewer | A reviewer must clear the findings | Follow requested changes or wait for review |
| Doesn’t pass | The portal lists broken rules or a security category | Fix the repository, then check the new commit |
| Rejected | The submission was not approved | Read requested changes and use Resubmit for review |
A passing version is not necessarily live. The default setting can require a publish request and reviewer publication; the portal also supports auto-publish settings for some later passing versions.
Open the plugin under Submissions and inspect Versions to monitor progress. After a fix, use Check for new commits when available. For updates, push to the tracked branch or move the tracked tag; you do not submit the form again. The last published version remains live while a new version is failing or waiting for review.
Safety checks developers should not skip
Anthropic’s official directory warns that plugins can include MCP servers, files, and other software outside Anthropic’s control. Before submission, document every external service, permission, retention period, and background action.
“I mean, I asked it to audit why my plugin submissions failed and fix the issue.” — @tarasshyn, X, describing a submission failure and audit workflow.
Use this preflight:
- Declare and document every outbound service.
- Explain permissions, setup, data flow, and retention in the README.
- Confirm that the tracked ref contains the code you intend to publish.
- Revalidate after every fixing commit.
- Disclose background indexing, telemetry, or costly automated behavior.
FAQ: Claude plugin submission
Is the GitHub repository required to be public?
Yes. Anthropic’s current documentation says the repository must be public before the listing goes live.
Can I submit several plugins from one repository?
Yes, but each plugin folder is its own submission. Enter each relevant path separately in the portal.
Can I submit by pull request to the community repository?
No. Anthropic’s community marketplace README describes that repository as a read-only mirror and says direct pull requests are closed automatically. Use the developer portal.
Do I need to submit a remote MCP server separately?
If your plugin references a remote MCP server that you operate and the server is not already listed, submit it separately as an MCP connector.
What happens when validation fails?
Fix the repository, push the change, and validate again. Validation applies to a specific commit. After submission, use the portal’s new-commit check when available.
Does a passing scan publish the plugin automatically?
Not always. A passing version can still require Publish and reviewer publication. The portal’s auto-publish setting determines how later passing versions are handled.
Can I delist a published plugin?
Yes. Open the live plugin in the developer portal and request Delist plugin. Anthropic says the change can take time to reach every Claude app, and existing users may stop receiving updates.
For a public listing, the shortest route is: make the repository public, validate locally, submit Plugin bundle, fix commit-specific findings, complete data and compliance steps, and publish the passing version. Keep a team-only package private when directory reach does not justify public review and maintenance.