Plugins and marketplaces: how to evaluate before installing

The documentation pulls no punches. Plugins and marketplaces get described as "highly trusted components, capable of executing arbitrary code on your machine with your user privileges". And the installation screen adds to it: Anthropic controls neither which MCP servers, files or software arrive inside a plugin, nor can it verify that the plugin does what it promises.

That changes the question. It is no longer whether the marketplace deserves trust, but what to check before you press enter. And Claude Code already ships the tools for checking. Almost nobody uses them.

Before evaluating, you have to know what you are evaluating. A plugin is a directory of optional components, and the list runs longer than most people expect.

The four rows saying "yes" deserve attention, and two of them almost never appear in writing about plugins.

monitors/ defines commands Claude Code starts on its own while the plugin is active. Each line the command writes to standard output becomes a notification for the agent during the session. It is a legitimate and useful channel, and it is a background process you never asked for.

settings.json accepts two keys today, and one of them is large: agent activates one of the plugin's own agents as the main thread, applying its system prompt, its tool restrictions and its model. A plugin carrying that key changes Claude Code's default behavior on your machine.

bin/ adds executables to the Bash tool's PATH while the plugin stays active. A binary there under a common command name gets found ahead of the original.

None of that is a design flaw. It is what makes plugins useful, and it is why the documentation uses the phrase "highly trusted". The mechanics of hooks sit in hooks in Claude Code, and those of MCP servers in MCP in practice.

Treating every marketplace as equivalent is the most common mistake. Three layers exist, with quite different guarantees.

Two readings matter here.

The first: the official marketplace registers itself the first time you open Claude Code in interactive mode. You already have a marketplace added without asking, and it is the only one with human curation.

The second: the community one pins each plugin to a specific commit in the catalog, and CI moves that pointer as the author publishes. That gives traceability, and it means the content approved in triage carries no guarantee of matching what you download weeks later.

For everything outside those two lists, a team repository and a local marketplace included, no review exists. Only what you check exists.

Claude Code already shows enough for a serious evaluation. The details screen, under /plugin, the Discover tab, carries three fields most people skip:

• Context cost, an estimate of how many tokens the plugin adds to your window on every turn
• Last updated, to see whether the project is alive
• Will be installed, the list of commands, agents, skills, hooks and MCP and LSP servers it adds

Not every plugin supplies that data. In a local or custom marketplace, the context cost and the date may go missing, and the list turns into "components will be discovered at installation". That message is information, not noise: it says you are about to install without knowing what arrives.

Outside the interface, three commands do the heavy lifting:

# a complete inventory of an installed plugin
claude plugin details <plugin>@<marketplace>

# the same validation the review pipeline runs
claude plugin validate ./plugin-path --strict

# load without installing, for this session alone
claude --plugin-dir ./plugin-path

The last one is the most underrated. --plugin-dir loads the plugin into the current session without installing anything, and it accepts a .zip file too. Cloning the repository, reading hooks.json and .mcp.json with your own eyes, and testing that way costs five minutes.

The order I follow:

1. Read the Will be installed section. Any hook, MCP or monitor? The evaluation gets stricter.
2. Open the repository and read hooks/hooks.json, .mcp.json and monitors/monitors.json. They are short files.
3. Check whether bin/ exists and what sits inside.
4. Check whether a settings.json carries the agent key.
5. Look at the last update date and the context cost.
6. Test with --plugin-dir before installing for real.

After installing, the Errors tab in /plugin shows what failed to load.

If the question is which one to install before knowing how to evaluate, the catalog of skills and commands carries what already passed that screen here.

How to make sure you get what you reviewed

Reviewing a plugin and then receiving different content is a real possibility, because ref points at a branch or tag that moves. Plugin sources solve that, and it is worth knowing for when you maintain the team's marketplace.

Seven source types exist: a relative path, github, url, git-subdir, npm, archive and command. The first three git ones accept sha, which pins an exact commit:

{
  "name": "formatter",
  "source": {
    "source": "github",
    "repo": "my-org/formatter",
    "sha": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0"
  }
}

With ref and sha together, the sha is what counts. The installation keeps working even if the branch ref pointed at got deleted, as long as the commit stays reachable in the repository.

The archive source, which downloads a zip over HTTPS and needs neither git nor npm on the machine, accepts sha256 for the same purpose.

It is the difference between "install the latest thing this author publishes" and "install what I read".

A plugin carries a recurring cost, and it shows up nowhere in the conversation.

The context cost listed on the details screen is per turn, and not per session. Skill descriptions, agent definitions and MCP tool names enter the prompt and get resent with every message. Since 90% of a session's cost is rereading context, a handful of forgotten, never-used plugins comes out more expensive than it looks.

A switching cost exists too. Enabling or disabling a plugin mid-session bills on the next request: the new components announce themselves in content appended to the conversation. And if the plugin brings MCP servers whose tools are not deferred by tool search, the change invalidates the cache and the next request rereads the whole conversation. That is why /reload-plugins warns and asks for --force when the reload carries that effect.

Claude Code helps you find the dead weight. In the Installed tab, plugins you installed and have not used for at least two weeks, across ten sessions or more, appear under the Not used recently heading. That is the list to review from time to time.

At installation you choose among three scopes, plus one only an administrator sets:

Choosing Project publishes a security decision for the whole team. It deserves the same care as a package.json.

Three behaviors surprise people in operation.

Removing a marketplace uninstalls its plugins. The documentation warns about it, and the warning goes unnoticed.

Automatic updating carries different defaults. On in Anthropic's official marketplaces, off in third-party and local ones. If you added a team marketplace, it does not update itself unless someone turns that on, or the administrator marks autoUpdate in the extraKnownMarketplaces entry.

A command source plugin runs a command on your machine. It is a source type where the marketplace, instead of pointing at a repository, points at a local command printing the plugin's path. It runs at installation and once per session, in the background, on a cadence of its own that ignores the marketplace's automatic update setting.

The design around that is careful, and worth knowing. The command has to be printable ASCII, at most 500 characters, with no runs of four or more spaces, and the documentation states the reason: so a person can review the entire command they are accepting. Claude Code shows the exact string before installation and runs the command you accepted and no other. If the author changes the command, the re-runs stop until you review and accept again.

Once the decision stops being individual, four managed settings cover almost everything:

One precedence detail prevents a false sense of control: strictKnownMarketplaces matches the source marketplace, and not the entries inside it. A person can still install a command source plugin from an allowed marketplace. Closing that needs disableCommandPluginSources alongside it.

The permission model governing the rest of execution sits in permissions and auto mode, and the broader operating checklist in Claude Code in production.

Does Anthropic review the plugins in the marketplaces?

It depends on the marketplace. Anthropic curates the official one, with inclusion at its discretion. The community one accepts plugins that passed automated validation and security triage, and pins each to a specific commit. For any other marketplace no review exists, and the documentation states that Anthropic neither controls nor verifies what arrives inside a third-party plugin.

Can I test a plugin without installing it?

Yes, and it is the most useful step in the evaluation. claude --plugin-dir ./path loads the plugin for that session alone, without installing, and it accepts a .zip too. There is also claude plugin validate, which runs the same check as the review pipeline.

Does an installed, never-used plugin get in the way?

It gets in the way of your wallet and your context. The cost listed on the details screen is per turn: skill descriptions and tool definitions get resent with every message. The Installed tab groups under Not used recently what you have not used for two weeks across ten sessions, and that is the list to clean.

What is the difference between disabling and uninstalling?

Disabling keeps the plugin on disk and takes its components out of the session, which already removes the context cost. Uninstalling removes it for good. And remember that removing the source marketplace uninstalls every plugin that came from it.

• Anthropic — Claude Code Docs: Discover and install prebuilt plugins. Accessed 20 August 2026.
• Anthropic — Claude Code Docs: Create plugins. Accessed 20 August 2026.
• Anthropic — Claude Code Docs: Create and distribute a plugin marketplace. Accessed 20 August 2026.
• Anthropic — Claude Code Docs: How Claude Code uses prompt caching. Accessed 20 August 2026.
• Anthropic — Claude Code Docs: Configure permissions. Accessed 20 August 2026.

Verified on 20 August 2026.

Review trigger: revisit when (a) a plugin's settings.json accepts keys beyond agent and subagentStatusLine, (b) the community marketplace changes its triage criteria or stops pinning commits, or (c) the list of seven plugin source types changes.