Plugin marketplaces

Plugins live in marketplaces - curated places where you can find, install, and update them. As of 2026, the ecosystem is young, but there are already real options for finding quality plugins. This page is how to find them, how to vet them before you trust them with your data, and how to publish your own when you've built one worth sharing.

Where plugins live today.

Start with the official marketplace. It's curated; quality is high; nothing there is going to wreck your setup. Once you have a feel for what a good plugin looks like, branch out to the community ecosystem.

How to vet a plugin before you install it.

A plugin runs with your agent's permissions. That means it can touch your files, hit your APIs, and use your credentials. Installing one is a trust decision. Here's the checklist:

Most of these are fast checks. Ten minutes before installing a plugin saves you months of "why is my agent doing weird things?" later. Don't skip.

Installing.

From a marketplace:

/plugin install telegram@claude-plugins-official

Directly from a GitHub repo:

/plugin install github:user/repo

Claude Code downloads the plugin, registers the MCP servers, makes the skills invokable, and wires up the hooks. Uninstall with /plugin uninstall <name> and everything gets reversed cleanly.

Publishing your own plugin.

If you've built a workflow you'd use across projects (or share with your team), package it as a plugin. The high-level steps:

1. Create a directory with the plugin structure: manifest, MCP servers, skills, hooks, any assets.
2. Write a manifest declaring everything included: name, version, dependencies, permissions requested.
3. Push to GitHub with a clear README. Include install instructions.
4. (Optional) Submit to the official marketplace. Anthropic reviews; if approved, your plugin shows up in claude-plugins-official for everyone.

Conventions that make plugins trustworthy.

If you publish, follow these. They're not required, but they're how users decide whether to trust you.

• Semantic versioning. MAJOR.MINOR.PATCH. Don't break compat in minor releases.
• Include a changelog. Users need to know what changed when they update.
• Document required environment variables clearly. Nobody should have to read your source to figure out what API keys you need.
• Ship a minimal reproduction example. A 30-second "here's how it works when it works" is the fastest confidence-builder.
• Sign your commits if possible. Supply-chain trust matters for code that'll run with someone else's credentials.

Plugin hygiene once published.

• Update regularly. Dependencies rot. MCP protocol evolves. Old plugins break silently, which users hate.
• Deprecate cleanly. If you can't maintain it anymore, mark the repo deprecated, publish a final notice, and link to any fork continuing the work.
• Keep permissions tight. Requesting fewer permissions than you think you need is always the right default. Users trust minimal plugins more than maximal ones.
• Respond to security reports quickly. The response time to a CVE is part of your plugin's reputation. If someone files a security issue, treat it like an oncall page.

The ecosystem in context.

Plugins are where the agent ecosystem becomes a real marketplace - people building things for people, not just companies building things for themselves. Every plugin you install expands what your agent can do without you having to write a line of integration code. Every plugin you publish can save someone else the same work. That's the flywheel.

If you're just starting, install a few from the official marketplace and see how they feel. If you find yourself wishing a plugin existed that doesn't, that's probably your first one to build.