Claude now has a public directory where developers can put forward their own plugins. It’s a new route from a finished tool to its users, but not a promise of installs: being in the directory and having demand for the product are different things. Below: what exactly to publish, how submission works, where moderation trips you up and what small experiment will help you decide whether this channel is worth investing in.
What’s new and why a developer should care
When I checked the Claude Marketplace page on 30 September 2026, it showed 340 plugins. The number is live and may change as soon as this article is out. Alongside development tools there are integrations with services and specialised workflows. A plugin’s listing gives the user a description, details about the author and a way to install it; some listings show an install count. But the number on a popular project’s listing says nothing about how many installs a new, unknown plugin will get.
The Anthropic directory itself lives inside Claude, under Customize: on claude.ai, in the desktop and mobile apps and in Cowork. A plugin someone adds there also shows up in their Claude Code sessions, as a synced <name>@synced. Claude Marketplace on claude.com is a showcase where you can browse these listings from the outside; there’s no separate submission for it, applications go to the directory. The official Claude Code marketplace, claude-plugins-official, is another story: it doesn’t take applications through the Anthropic portal, and a place in it is negotiated through a partner contact at the company.
For an independent author this matters. On top of the repository and your own install instructions, you get one more place to be discovered. It can bring in a user who is already looking for a solution inside the Claude ecosystem. The public size of the directory doesn’t tell you how many of those users will come to your product in particular.
The same directory also holds MCP connectors, which are a different type of listing. A connector is a single remote MCP server that gives access to tools or data; a plugin can bundle a link to it together with skills and a workflow. If you run your own remote server, Anthropic advises submitting it separately as a connector, and the plugin as a second application on top of it.
A plugin is more than a link to an MCP server
A Claude plugin is a folder with a .claude-plugin/plugin.json manifest. Inside there can be skills, MCP connectors, commands and subagents. You don’t have to put everything in at once. The point of bundling is that the user installs a complete workflow, not a set of components they then have to figure out how to connect.
Picture a tool for reviewing pull requests. One MCP server gives access to the repository and comments. A skill explains when to run the review, how to tell bugs from matters of taste and what result to hand back to the author. A command lets you trigger the review explicitly. This is an example of plugin design, not a description of a finished product: the value comes from the chain of actions, not the number of files.
If you already have an MCP server, you don’t have to turn it into a complex package just to submit it. Start with one user task: what the person gets after installing, what access the plugin will need and why the result is better than running the same server by hand. For background on how agents are given a verifiable workflow, we have a breakdown of the AI agent engineering process. And a separate example of an integration through MCP is our piece on Codebase Memory.
Support for components differs between Claude apps. For example, according to Anthropic’s technical guide, skills and commands work across different surfaces, while a local MCP server doesn’t run in a regular claude.ai chat. So you can’t promise “works everywhere” in the description without testing every scenario you need.
How to prepare and submit a plugin
The route is best taken in this order.
- Build a minimal working package. A manifest, a README, a clear description of the task it solves, and the components without which the workflow doesn’t work. In its build guide, Anthropic calls a README and a licence mandatory for the directory and advises testing in every target app. Don’t put secrets in
.mcp.json: the package files reach everyone who installs it. - Test it on a real scenario. Check the install, the service connection, the permissions and the expected result. A syntactically valid manifest doesn’t prove the workflow is useful or that authorisation will work for someone else.
- Check the structure. The submission docs recommend the command
claude plugin validate ./your-plugin; the Claude Code publishing guide also shows a stricter option with--strict. The command only checks the file format: it can’t see the README, the licence, a taken name or the directory’s other rules. Fix errors before submitting rather than leaving them for moderation. - Put the plugin in a GitHub repository. The directory only reads plugins from github.com. A private repository is fine to start with: according to the submission page, it can be checked and submitted if your GitHub account with push access to the repository is connected to claude.ai, you’ve agreed to the source code being uploaded to Anthropic (it will go through automated checks and be seen by reviewers) and the Claude GitHub App is installed on the repository. Checks and review can start while the code is private, but the repository has to be made public before it goes into the directory. Otherwise the portal won’t let the publication through.
- Submit through the developer portal. Applications go through the developer portal on claude.ai: Submit new, then Plugin bundle, a link to the repository and the path to the plugin folder if it isn’t at the root. Before sending, click Validate: the button doesn’t send anything for review, it only produces a report. The portal checks more rules than the local command, and the result applies to a specific commit. Pushed a fix? Check again.
You can submit from any paid plan. On Pro and Max, from your own account, with no roles to check. On Team and Enterprise, the organisation owner (the Owner role) submits, and on Enterprise also a member whom the Owner has given the Directory permission through a separate role. You can’t submit from a free account, and the old form in Claude Console is no longer supported. A listing belongs to the account or organisation it was submitted from: the portal won’t accept the same repository folder from another organisation. So submit straight away from where the plugin will live. Anthropic changes the terms, so before applying, check against the page about the directory, not someone else’s summary.
Submitting doesn’t mean appearing in the directory instantly. The portal runs every plugin version through automated validation and a security check, and a person looks at a new listing before it goes live. There’s no fixed review time; the status of an application is visible in the portal. There’s no separate application for the Verified badge or for a place in the directory: Anthropic decides both during review. After that, updates go out without resubmitting. The directory picks up new commits on the tracked branch by itself, on a schedule (in my observation, roughly every six hours) or immediately if a GitHub push webhook is set up, and checks them again. Whether a version goes live straight away or only after a reviewer approves it depends on the publishing settings of that particular plugin. If plugin.json has a version field, bump it with every release: that’s how installed copies know an update is out.
Before investing in packaging, check the idea against the directory policy. Some categories aren’t allowed in without separate written permission from Anthropic. Under section 4.B, that covers software that generates images, video or audio with AI models. The exception is design tools that make slides, diagrams, charts, interface mock-ups or logos as part of a workflow, as long as image generation isn’t sold as a standalone service. The same section covers plugins that transfer money or make payments on the user’s behalf, and advertising plugins. A cover or voiceover generator shouldn’t count on the directory; that leaves your own marketplace.
Besides the bans, the policy sets a mandatory minimum for developers. Everyone needs a working support contact, documentation (how the plugin works, why it’s needed and what to do if something breaks) and at least three working example prompts or scenarios. If the plugin collects user data or connects to a remote service, add a link to a privacy policy: what data it collects, how it uses it and how long it keeps it. Anthropic also asks for a standard test account with sample data so it can check all the functionality. For a plugin that works through an external service, it’s worth preparing that before submitting. A plugin may only call APIs and domains you own or control, or connectors already approved in the directory. Hidden, encrypted and obfuscated instructions are banned: anything that steers Claude’s behaviour must be readable by a human. Pulling in instructions from external sources on the fly isn’t allowed either.
What the portal checks: lessons from my submission
I took my own plugin for editing vertical videos, reels-montage, through this moderation in early October 2026. The security check took a couple of minutes; approval and publication, about an hour. That’s one case, not the norm: Anthropic doesn’t promise a review time. Below is what actually trips you up, checked against the pre-submission checklist.
It all starts with structure. The portal expects an actual plugin: a folder with .claude-plugin/plugin.json and skills in skills/<name>/SKILL.md. It will also accept a folder of skills without a manifest, but with a note: such a listing will only be shown in Claude Code, not in claude.ai or Cowork. A README of at least 40 words (code doesn’t count) and a licence are mandatory. One application, one plugin folder: in a repository with several plugins, each is submitted separately, and the folder path can’t be changed after submission.
Choose the plugin’s name (name) once and for good: it’s what the plugin is installed and updated by. The portal won’t let through reserved words like claude, anthropic or official. A name made only of generic words, such as test-plugin, or one that looks like someone else’s brand will send the application to a reviewer. A skill’s description, under the Agent Skills specification, can be no longer than 1,024 characters. The icon and links for the listing are set right in plugin.json: in the icon field, a path to an image inside the plugin; in privacyPolicyUrl, supportUrl, documentationUrl and termsOfServiceUrl, https addresses. Claude Code doesn’t read these fields. claude plugin validate accepts them silently from version 2.1.281, while earlier versions call them unknown. That’s only a warning, though a run with --strict on earlier versions will fail.
The rule on keys is strict. You can’t hard-code them into files, not even in README examples, or take them from the user’s environment, like $GITHUB_TOKEN. A key is requested through userConfig in plugin.json with sensitive: true and substituted as ${user_config.KEY}. A key in a file blocks the submission; reading an environment variable sends the version to a reviewer.
Much of what the scanner finds doesn’t block the submission but sends the version for manual review. That’s not a rejection: a person looks at a new listing anyway. Manual review is triggered by files over 256 KiB (except images and fonts), a plugin with more than 512 files, binaries such as .ico, .pdf, .zip or compiled programs, and packages launched through npx or uvx, even with a pinned version. One pitfall that caught me out was the exclamation mark: in a skill’s text, ! before a backtick is the syntax for running a shell command, and the scanner took even a stray ! in a code example for a command.
Two more lessons are about how a plugin lives after installation. The installed plugin’s folder is a cache: on update its contents are replaced, so user data and settings aren’t stored there. For those there’s the ${CLAUDE_PLUGIN_DATA} directory, which survives updates, userConfig or the project folder. Also, a plugin from the directory will appear in every Claude app, not just Claude Code. If a skill needs local programs like ffmpeg, have it check the environment as its first step and say honestly that it only fully works in Claude Code. And it’s better not to have a bin/ folder at the plugin root: with one, claude.ai and Cowork won’t install the plugin at all.
Look for a published plugin in claude.ai: Customize > Plugins > the Discover tab. The Claude Marketplace showcase on claude.com is, by all appearances, curated: getting into the directory doesn’t mean ending up there.
If you don’t need the directory yet: your own marketplace
You can create your own marketplace for Claude Code. To do this, you put a .claude-plugin/marketplace.json file in a repository, listing the plugins and the sources to load them from. A team or community adds this marketplace and installs the packages it needs. The repository can be private if only your own team is meant to have access.
This is a different distribution channel, not a way round the checks that lands you in Anthropic’s public directory automatically. You’re responsible for the link, trust, documentation, updates and bringing people in. On the other hand, you can first try the product out on a small group and fix the rough edges before submitting publicly. For an internal tool this route sometimes makes more sense: it doesn’t need a place in the shared directory at all.
Few competitors doesn’t mean many installs
340 entries is the size of the directory on the day I checked, not an estimate of demand for each type of tool. It already contains well-known projects and familiar integrations that a new author competes with for attention. You can’t infer from the total how many search impressions a listing will get, what position it will land in or what share of those who view it will install the plugin.
That said, the lack of guaranteed traffic doesn’t make the channel useless. The directory can offer a simpler, trusted install path and bring in people who intend to solve a task. But that’s a hypothesis for a specific plugin. Even a big install count for another author doesn’t prove the same result will repeat in your niche: projects differ in audience, age, recognition and promotion.
Before the experiment, phrase one testable bet: “Users looking for solution X are willing to install a plugin to get result Y.” Then separate two questions: is there demand for the task and does the directory work as a source of discovery. If you bring in an audience from your own channel, installs may confirm the product’s value but won’t prove the directory delivered the traffic.
A small experiment instead of a big bet
Pick a narrow scenario you can demo in a few minutes: one input, one clear result, clear access permissions. Give the plugin to a few people from the target audience before submitting and see whether they could install it without your help, complete the task and wanted to do it again. Write down the reasons people drop off: an unclear description, permissions that are too broad, complicated authorisation, a weak result.
After publication, the plugin gets a Usage tab in the portal, the main tool for this test. It shows installs, active accounts and retention, with installs broken down by app and by where the person came from. The directory funnel is shown separately: listing views, clicks on the install button, installs. Below that, how often each skill, command and MCP server fires, load errors and the share of failed calls. You can take a period of up to 90 days and export it to CSV. The numbers are recalculated once a day, and until there’s real data the tab is marked Preview and shows sample numbers. Don’t mistake them for yours.
Note the date the listing went live and watch the sequence: listing views, installs, a successful first run, repeat use. The tab won’t show feedback or reasons for dropping off; get those through direct conversations with users, not guesswork. Compare the directory funnel with the same funnel for your own link to the repository or marketplace. The breakdown of installs by source helps separate the directory’s contribution, but if you’re actively promoting the plugin in your own channel during the same weeks, some of the “directory” installs may still come from you.
Decide in advance which observation will make you keep going, and which will make you change the packaging or look for another channel. There’s no universal install count after which a plugin has “taken off”: a narrow paid tool and a free mass-market skill are different stories. A good outcome of the experiment isn’t necessarily lots of downloads, but a clear answer about who needs the product and how those people find it.
What to do with all this
If you have an MCP server, a set of skills or a working tool for Claude, try describing it in one sentence from the user’s point of view. Then check the idea against the directory policy, build a minimal plugin, test the install and permissions, try the scenario out on a small group, and only after that decide whether to go into the directory. A place in a list isn’t a product or a marketing strategy. But if the tool really solves a pain point, it now has one more route to the people who need it.
Submission terms and links were checked on 5 October 2026.
