How to Get Listed in the Claude Plugin Marketplace: Complete Submission Guide

Updated September 2026

To get a plugin listed in Claude's public plugin directory, put the complete plugin in a public GitHub repository, validate it with claude plugin validate, review the directory terms and policy, and submit the repository link through the Claude.ai or Console form with the required organization permission. Anthropic performs basic automated review before directory inclusion. Additional Anthropic Verified status is a separate review and is not guaranteed.

That process is intentionally different from publishing an MCP server alone. A Claude plugin is a versioned package that can combine instructions, MCP connections, agents, hooks, commands, and other components into one coherent workflow.

Understand the three distribution routes

Claude's documentation uses both directory and marketplace language. The current public submission page describes a community-driven plugin directory surfaced in Claude Code as claude-plugins-official. Separate Claude Code documentation reserves several marketplace names for Anthropic and distinguishes community review from curated or verified placement. The practical rule for a publisher is simple: use the official in-app submission form, describe the package as a community submission unless Anthropic grants another status, and never promise an Anthropic Verified badge.

The MCP Connectors Directory is separate. If you are submitting a complete Claude workflow that includes MCP, use the plugin path. If the product is only an MCP connector, check the current connector-specific route before treating the plugin directory as a substitute.

What makes a Claude plugin worth listing

Anthropic's guide emphasizes a coherent job, not a bag of unrelated extensions. A good plugin gives Claude what it needs to complete a category of work end to end.

For example, an incident-response plugin might include:

• an MCP connection to monitoring and ticket data
• a skill that defines the investigation sequence
• a command for starting a release check
• an agent for gathering evidence in parallel
• a hook that performs a safe local validation

Each component should support the same user job. If users would install only one piece and ignore the rest, you may have several plugins rather than one.

The recommended package anatomy

Claude Code can auto-discover a plugin without a manifest, but a public package should normally include one so its identity, version, author, and component paths are explicit. When included, the manifest belongs in .claude-plugin/plugin.json. Other components belong at the plugin root.

my-plugin/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── my-workflow/
│       └── SKILL.md
├── agents/
├── hooks/
├── commands/
├── .mcp.json
├── SETUP.md
└── README.md

You do not need every directory. Include only the components the workflow uses. Empty directories and placeholder capabilities make the package harder to audit.

A minimal manifest looks like this:

{
  "name": "my-plugin",
  "description": "What the plugin helps the user accomplish",
  "version": "1.0.0",
  "author": {
    "name": "Your name or company"
  }
}

Use a stable, non-impersonating name. If you set an explicit version, bump it when publishing changes so users can receive the update. Keep a changelog for meaningful releases.

Build each component for review

Skills

A skill needs a clear trigger, bounded instructions, referenced resources that exist inside the package, and a verification step. Do not use a skill to hide permissions or override user intent. Keep the workflow understandable to a reviewer reading the files in GitHub.

MCP configuration

A plugin can include remote MCP, local MCP, or other supported MCP configurations. Declare only the connection the workflow actually needs. Explain required accounts and permissions in the README and setup flow.

Anthropic recommends directory-listed connectors or connectors from known developers because users receive fewer warnings and reviewers have clearer provenance. That is a recommendation, not permission to skip your own security review.

SETUP.md

If the plugin requires an MCP server, a SETUP.md skill can guide Claude through configuration. Make it idempotent and explicit:

1. State the prerequisite account and permission.
2. Explain which local or remote setting will change.
3. Ask before making a consequential change.
4. Verify the connection with a harmless request.
5. Give the user a clear recovery or uninstall step.

Never put a real secret in the repository, an example command, a screenshot, or a test fixture. Use placeholders and guide the user to the service's secure credential flow.

Agents, hooks, and commands

Agents should have a narrow role and clear completion condition. Hooks should be predictable, documented, and safe to run in the intended environment. New command-style workflows should generally use the current skill structure where the documentation recommends it.

The public repository is part of the trust surface. A reviewer and prospective user should be able to find every executable action and understand why it exists.

Step 1: test locally from a clean session

Load the plugin from its directory during development, then start a fresh Claude Code session and test the same way a new user will experience it.

Cover at least:

• first installation
• the primary successful workflow
• missing prerequisite or credential
• refusal or clarification for an unsafe request
• MCP unavailable or authentication failure
• repeated installation or setup
• uninstall or disable path
• upgrade from the previous version

Do not test only on the maintainer's machine. Hidden environment variables, cached dependencies, existing marketplace configuration, and already authenticated MCP connections commonly make a broken package appear complete.

Step 2: validate the package

Run:

claude plugin validate ./my-plugin

The validator checks the manifest, hook configuration, and frontmatter in standard component directories for syntax and schema problems. In continuous integration, strict mode can turn warnings into failures:

claude plugin validate ./my-plugin --strict

Validation is necessary, but it does not prove the workflow is useful or safe. A structurally valid hook can still be surprising. A valid skill can still activate too broadly. A valid MCP configuration can still request excessive access.

Step 3: make the GitHub repository submission-ready

Claude's current public-directory submission requires a public GitHub repository. Closed-source plugins are not accepted on this path.

Before submitting, verify the repository includes:

1. A clear README with the user job, supported Claude surfaces, setup, permissions, and examples.
2. The complete plugin source at an obvious path.
3. A valid manifest and no unresolved local paths.
4. A license and maintainer contact.
5. Security reporting instructions.
6. No credentials, customer data, internal endpoints, or private screenshots in history or fixtures.
7. Release tags or an explicit versioning policy.
8. A clean validation result from the commit you intend to submit.

Installed plugins are copied into a cache. Do not rely on files outside the plugin directory. References that work only because the repository sits beside another local project will fail for users.

Step 4: review permissions and data access

Write a short permission inventory for humans:

The plugin's code, README, and actual behavior should agree. Do not describe a connector as read-only if a bundled workflow can publish, message, delete, or modify external state.

Read the current Anthropic Software Directory Terms and Software Directory Policy immediately before submitting. Policies can change faster than a tutorial. Treat the official form and policy as the final authority if a field or requirement differs from this September 2026 walkthrough.

Step 5: choose the submission account

Claude currently provides two in-app forms:

• Claude.ai: requires a Team or Enterprise organization and directory-management access. Organization owners have it by default, subject to current enterprise controls.
• Console: requires a Developer, Admin, or Owner role. An individual author can create a Console organization and submit without joining a claude.ai Team or Enterprise organization.

Sign into the organization that will own the listing. The public repository, author identity, support path, and submission account should match well enough that a reviewer can identify the maintainer.

Step 6: submit the public repository

Use the official Claude.ai submission form ↗ or Console submission form ↗ and provide the GitHub repository link. Submit the exact repository and commit state you validated.

Prepare concise answers for:

• the job the plugin completes
• the intended users
• the components included
• external services and MCP connections
• setup and permissions
• the primary user workflow
• support and security contacts

Do not use private operational details as proof. A reproducible public example and a clean test fixture are more useful to review than an internal customer name, production credential, or screenshot of private data.

Review times vary with queue volume. Do not plan around a fixed approval date that Anthropic has not promised.

After publication, updates pushed to the public GitHub repository are picked up automatically. Claude's current submission guide says its CI mirrors the changes to the public marketplace and screens each update, so the form does not need to be resubmitted for routine updates. Still validate, version, test, and review every release before pushing it. Automatic delivery makes a weak release reach users faster too.

Community listing versus Anthropic Verified

The public plugin directory is community-driven. Anthropic performs basic automated review before adding submissions. An Anthropic Verified badge indicates additional quality and safety review.

These are separate outcomes:

• directory inclusion does not guarantee Anthropic Verified status
• a clean automated review does not replace the user's own source and permission review
• a badge should never be implied in your listing, logo, repository, or marketing before Anthropic grants it

This distinction matters because "official marketplace" can describe the catalog surfaced by Claude Code, while "Anthropic Verified" describes additional review of a particular plugin.

If public listing is not the right route

For a private company plugin or controlled beta, publish your own Claude Code marketplace instead of exposing the source only to satisfy a public-directory requirement.

A marketplace has its own .claude-plugin/marketplace.json that names the marketplace owner and points to one or more plugin sources. Users add the marketplace, then install a named plugin from it. Use a distinct marketplace name and avoid the names Anthropic reserves for official catalogs.

This route gives you controlled distribution, but it does not waive product security. Pin reviewed sources, define update behavior, protect credentials, and document the trust boundary.

Common submission failures

After listing: measure the product, not the install

Marketplace distribution gives you reach. It does not tell you what users accomplish after the plugin connects to your MCP server.

Repository traffic, installs, and tool-call counts miss critical questions:

• What did the user want to do?
• Which tools did Claude select across the full journey?
• Did a technically successful tool result produce a useful answer?
• Did Claude retry, loop, or abandon the workflow?
• Which capabilities do users repeatedly request but cannot access?
• Which accounts show product feedback or commercial intent?

Flowlines MCP observability instruments MCP servers with OpenTelemetry-compatible instrumentation and connects MCP interactions into complete behavioral sessions. It helps teams distinguish real adoption from noisy call volume, inspect recurring problems, and understand use cases and outcomes without replacing the operational telemetry stack.

For the other major distribution path, read the OpenAI Plugins Directory MCP submission guide. Continue with the MCP analytics guide, the production observability guide, or the OpenTelemetry instrumentation guide. Developers working in Claude Code or Codex can start the guided Flowlines plugin setup.

Final Claude submission checklist

1. The plugin solves one coherent workflow.
2. Public directory, direct install, or private marketplace is the right route.
3. The complete public submission source is in GitHub.
4. Any manifest is at .claude-plugin/plugin.json.
5. Skills, agents, hooks, commands, and MCP configuration are at the plugin root.
6. Every component is necessary and documented.
7. Setup avoids real credentials and private values.
8. Permissions and external services are clear before installation.
9. The plugin works from a clean clone and clean session.
10. claude plugin validate passes on the submitted commit.
11. Version and changelog are ready for updates.
12. The correct organization role can access the submission form.
13. The repository, maintainer, and support path are consistent.
14. Current directory terms and policy have been reviewed.
15. The launch plan measures user journeys and outcomes, not only installs.

Primary sources

• Claude: Submitting your plugin ↗
• Claude Code: Plugins ↗
• Claude Code: Plugin reference ↗
• Claude Code: Create and distribute a plugin marketplace ↗