MCP servers: when they are worth it

What you install when you install one covers the risk. This page covers the prior question, which is whether to install anything at all.

Anthropic's own trigger is specific and easy to apply: "Connect a server when you find yourself copying data into chat from another tool, like an issue tracker or a monitoring dashboard." Repeated manual transfer is the signal. One-off transfer is not.

Try a CLI first

The recommendation people skip, from the same documentation set: "CLI tools are the most context-efficient way to interact with external services."

If the service has a good command-line client and you already have it installed, Claude can use it today with no server, no configuration file, no credential handling and no new trust decision. Anthropic notes Claude is also effective at learning unfamiliar ones — Use 'foo-cli --help' to learn about foo, then use it to solve A, B, C.

So the ladder runs: paste it if it is once, use the CLI if there is one, and connect a server when neither of those holds.

The context cost is smaller than it used to be

The old objection to MCP was that tool definitions consumed context whether or not you used them. Tool search changed that, and it is the default: schemas load on demand instead of upfront, so a connected server costs the name rather than the full definition until something needs it.

One caveat on when that default does not apply. The documentation lists the configurations without tool search: a custom ANTHROPIC_BASE_URL, ENABLE_TOOL_SEARCH=false, and models earlier than the 4.5 generation on Google Cloud's Agent Platform. In those, the old arithmetic still holds and a large server is a real cost on every session.

Pick the scope deliberately

Three, and the choice is mostly about credentials and who else gets this.

Local is the default: "personal development servers, experimental configurations, or servers with credentials you don't want in version control."

Project puts a .mcp.json at the repo root and checks it in, so everyone on the team gets the same servers. Convenient, and it means adding a server is a decision you are making for colleagues rather than for yourself.

User covers servers you want across all your own projects.

What a server buys that a CLI does not

Live state, in a form Claude can query rather than one you have to fetch and paste. Authentication handled once, including OAuth refresh on a 401 without you re-authorising. And a shared configuration your team gets by cloning the repo.

That is a real set of advantages. They are worth it when the thing is part of your daily loop, and they are overhead when it is not.

Try this

Look at your last week. Count the times you pasted output from the same external tool into a conversation. Below about three, a CLI or a paste is cheaper than the server plus its trust decision. Above it, you have found the one that earns its place.

What goes wrong

Installing servers speculatively. Each is a standing trust decision and a set of tools in scope. A server connected for one experiment months ago is still connected.

Checking a server into .mcp.json without saying so. Project scope makes the decision for everyone who clones the repo, and most people never look at what a new config file added.

Reaching for MCP where a CLI exists. Anthropic's own guidance is the other way round, and the CLI needs no trust decision because you already made it when you installed the tool.

Reading tool search as a licence to connect everything. It defers the cost; it does not remove the attack surface, and the surface is the part that matters.

How to check it worked

A month after connecting one, ask whether you would notice its removal. If yes, it earned the trust decision. If you cannot recall using it, disconnect it — the tools stay in scope whether or not you use them, and an unused server is pure exposure with no offsetting benefit.