Which Claude Code plugins and MCP servers are worth using

How to judge whether a plugin earns its place

Start from the default assumption that you do not need it. Claude Code is already capable with the built-in tools. Every plugin and MCP server you add spends tokens describing itself to the model on each turn and widens the set of actions the agent can take wrong. So the bar is high.

A plugin earns its place when it removes a step you would otherwise do by hand in almost every session. Not a step you hit once a month. A step you hit constantly: finding the right code, checking the change is clean, running the tests, shipping it. If a plugin only helps in a narrow case, install it in the project that needs it, not globally.

The categories below map to that loop. They are the four points where the agent otherwise stalls or hands the work back to you. Get these four right and the rest of the plugin ecosystem is genuinely optional.

Context and retrieval: the highest-leverage category

This is the one to install first, and the one most setups skip. A retrieval MCP server gives the agent a way to fetch the exact code, docs, and prior decisions relevant to the task before it reasons. Without it, the agent rediscovers your codebase from scratch on every run: it greps, reads whole files, follows imports, and burns most of its budget locating things rather than solving anything.

The mechanism is simple. You index your files, your local vault, your docs once as retrievable chunks. The agent queries that index and pulls back the relevant few thousand tokens instead of streaming raw files or re-deriving facts the model has no reason to know. Context then tracks relevance, not repository size.

Quality: linting, review, and code health

The second category makes the agent check its own output before you see it. A quality plugin wires your linter, type checker, and a review pass into the agent loop, so a change comes back already formatted, typed, and self-reviewed instead of as a raw diff you have to police.

The value is not that these tools are new. You already run them. The value is that the agent runs them automatically and fixes what they flag in the same turn, rather than producing code that fails your pre-commit hook thirty seconds later. Pick one that reports back in a form the model can act on: structured findings it can address, not a wall of output it truncates and ignores. Keep this to a single quality plugin per project. Stacking three overlapping linters into the agent context wastes tokens and produces contradictory guidance.

Testing: close the loop so the agent verifies itself

A testing plugin lets the agent run your suite and read the results without you copying failures back into the chat. This is what turns Claude Code from a code generator into something closer to a developer, because it can iterate against real feedback: write, run, read the failure, fix, run again.

The distinction that matters is between a plugin that just executes tests and one that returns failures in a parseable form. The agent needs the failing assertion, the file, and the line, not a scrollback dump. When testing is wired in well, you stop being the loop between the change and its verification. You review the finished, passing work instead of shepherding every red-green cycle by hand.

Deploy: ship without leaving the session

The last category closes the outer loop. A deploy plugin gives the agent a controlled path to push a branch, open a pull request, trigger a build, or promote a release, so the work does not stall at a green test run waiting for you to switch windows.

This is also the category to scope most tightly. Deploy actions are irreversible in ways retrieval and linting are not, so give the agent the narrowest capability that ships the change: open the PR, do not force-push to main. A good deploy plugin is mostly guardrails. Used well, it means a task that starts as a natural-language request ends as a merged, deployed change with you approving at the gates rather than driving every command.

The stack, ranked, and what to skip

If you install nothing else, install a retrieval MCP. It changes both the quality and the cost of every session. Add a quality plugin next, then testing, then deploy, in that order, because each one depends on the agent already producing grounded, correct changes worth checking and shipping.

Everything outside these four is situational. Browser automation, design tooling, database clients, and the long tail of niche MCP servers are worth adding only in the projects that actually use them, and worth removing when they go quiet. The failure mode is not too few plugins. It is a global config with fifteen servers, most of them idle, each one spending context to advertise tools the agent will never call on this task. A small, deliberate stack beats a large one every time.