Claude plugins now have a self-serve front door. On September 25, 2026, Anthropic announced the directory submission portal for developers on paid Claude plans, and plugins are now "the main way to build third-party extensions for Claude." If you run an internal-tools or platform team, that raises two questions: how do you build a Claude plugin that gets through review, and should yours be in a public directory at all? This is part of our coverage of AI in the engineering workflow: tools, permissions and policy, and the answer to the second question is often no.
What a Claude plugin is
Per the plugin quickstart, a plugin is a folder that packages skills, MCP connectors, commands and agents, in any combination, so people add them together. Anthropic's announcement frames it more narrowly: plugins package MCP connectors, Agent Skills, or both.
There are two submission paths. A single MCP connector means pointing the portal at your remote MCP server. A plugin bundle combines MCP servers and skills, lives on GitHub, and you submit the repo. Skills have no path of their own. The docs say it plainly: put them in a bundle.
That distinction matters for how you ship. The publish page says that if you have a remote MCP server, you should always submit it as an MCP connector, even when a plugin you're submitting already references it. So for your own product that means two submissions: the server as a connector, then a bundle with your skills that references the server URL.
Who can submit
Pro and Max users can submit directly. On Team and Enterprise, an Owner can submit, and on Enterprise an Owner can also grant the Directory permission through a custom role under Organization settings > Roles. Other members ask an Owner. Free accounts can't submit. For a platform team, that means submission goes through whoever holds the Owner role, or a custom role you create for it, so sort that out before launch week. The directory publishing docs add that there's no partner program to apply to first, and that Anthropic checks each submission before it's listed.
Every version gets automated validation and a security scan, and a person reviews a new listing before it goes live. The docs don't give a review turnaround. They say review time isn't fixed, so don't plan a launch date around it.
Public listing or private rollout?
Most internal plugins shouldn't go in the public directory. A plugin that wraps your deployment tooling or your internal ticketing has no audience outside your company, and a public listing means a public repo before it goes live.
The alternative is org rollout, which is for Team or Enterprise plans. The org rollout docs say plugins you add that way "stay private to your organization." The route runs through Organization settings, under Plugins & skills, and Claude Code teams can also push plugins through managed settings. If you're already deciding what agents may touch, that sits next to the admin controls for Claude Code you've probably set.
| You want | Route |
|---|---|
| Strangers to find and install it | Public directory listing |
| Only your organization to have it | Org rollout |
Use the public listing when the plugin is a product or a developer-relations asset. Use org rollout when it's plumbing.
A platform team has one more reason to be careful with connectors: every MCP tool a plugin adds is a tool someone has to vet. The policy thinking in GitLab's default for agent tool permissions applies whether the connector comes from your plugin or someone else's.
How to build and submit a Claude plugin
1. Write the manifest
Create a plugin folder, then create .claude-plugin/plugin.json inside it. Put only the manifest inside .claude-plugin/. Everything else (skills, commands, agents) sits at the folder's top level beside it. Each plugin folder is its own submission in the portal, so a repo with three plugins means three submissions.
2. Add a skill and, if you run a remote server, .mcp.json
A skill is the smallest useful thing you can ship. If you operate a remote MCP server, add a .mcp.json pointing at it. Keep real credentials out of every file, documentation and examples included. The scan treats secrets as a blocker, not a warning.
3. Write the README and add a license
The pre-submission checklist asks for a README of at least 40 words in the plugin folder. Words inside code blocks don't count, so a README that's a single install snippet fails. Add a LICENSE file to the plugin folder, or set license in plugin.json. A missing README or license blocks the submission.
4. Test locally and validate
Load the plugin from disk with claude --plugin-dir, run its skills, and then run claude plugin validate ./<plugin-folder>. Don't treat a clean local result as a pass. The submission guide warns that the portal's Validate step runs more checks than the command does.
5. Push to GitHub
Commit the folder and push it. Leave system files out of the repo, since they trip the scan: .DS_Store, Thumbs.db, desktop.ini and __MACOSX all block. The repository can stay private while you validate and submit, but it must be public before the listing goes live.
6. Submit as a plugin bundle in the portal
In the developer portal, choose Submit new, then Plugin bundle. The form walks through Source (Validate is a button inside this step), Listing details, Data handling and Compliance. On Review and submit, choose the update mechanism, either a GitHub push webhook or a schedule, and press Submit for review. Anthropic says each submission is checked and safety-scanned as soon as you submit, so problems surface early rather than after a reviewer has looked at it.
One limit to know about: an organization can create up to 10 submissions in any 24-hour period. That's plenty for one plugin, and tight if you're bulk-submitting a monorepo of them.
7. Publish a passing version
By default, a passing version isn't live until you select Publish, which records a request for an Anthropic reviewer. For updates, merge to the tracked branch, and the directory picks up the commit and checks it. Updates go through the same scan as the first version, and a held version or a failed security scan blocks the versions after it.
What validation and the security scan check
The scan looks for behavior a plugin doesn't disclose, such as sending data elsewhere, running hidden code, or changing Claude's permission settings. Three outcomes are possible: passes every check, held for a reviewer, or doesn't pass. A first submission that fails is rejected, and a later version that fails can't go live.
Here's how the common findings sort, drawn from the checklist and the submission docs:
| Finding | Result |
|---|---|
Launcher (npx, uvx) not pinned to an exact version | Blocks |
| Real credentials anywhere in the files, docs and examples included | Blocks |
| Non-https MCP server URL | Blocks |
System files such as .DS_Store | Blocks |
| Missing README or license | Blocks |
| Binaries | Held for a reviewer |
| Any non-image, non-font file at 256 KiB or more | Held for a reviewer |
| More than 512 files | Held for a reviewer |
| Installs from a lockfile | Held for a reviewer |
| Minified or otherwise unreadable code | Held for a reviewer |
On the pinning rule, the checklist wants every package a launcher runs pinned to an exact version, such as npx <package>@1.2.3, not a range or @latest. A launcher pinned to an exact version is still held, not blocked, while an unpinned one is blocked. An .npmrc, bunfig.toml or uv.toml alongside a launcher blocks too.
Held isn't failed, but it does put a person in your path, and that's the thing you can't schedule. If you're aiming for a clean pass, ship readable source, keep files small and don't commit build output.
Review and usage after you submit
Each version lands in one of the three scan states: passed, held, or failed. A rejected submission continues on the same submission: fix the findings and use Resubmit for review. New submissions, including drafts and withdrawn ones, count toward the 10 limit, and you get one submission per repository and folder.
Once a plugin is live, its Usage tab shows installs, versions, how often each skill and MCP server runs, and error rates. Anthropic's announcement describes the same analytics as installs by product surface and version. That's the data you'd want before deciding whether a plugin earns its maintenance time.
FAQ
Who can submit a Claude plugin?
Pro and Max users can submit directly. On Team and Enterprise, an Owner submits, or on Enterprise grants the Directory permission through a custom role, and other members ask an Owner. Free accounts can't submit, and there's no partner program to join first.
Do I submit the MCP server separately?
Yes. Anthropic says to always submit a remote MCP server as an MCP connector, even when a plugin you're submitting already references it. If you also have skills, make a second submission: a plugin bundle with the skills that references the server URL, because skills aren't a submission type on their own.
Can I keep the repository private?
Only for a while. The repository can stay private while you validate and submit, and it must be public before the listing goes live. If the code can't be public, use org rollout instead.
How do updates reach users?
Merge to the tracked branch. The directory picks up the commit and checks it. Every version gets the validation and security scan again. By default a passing version goes live only after you select Publish, which records a request for an Anthropic reviewer.
Can a company keep a plugin private?
Yes. Plugins added through org rollout stay private to your organization.