Installing an MCP server takes one command. Living with the wrong one takes weeks: a token that is too broad, a server that stopped being maintained, a tool whose definition eats a fifth of every request.
This checklist is what we run before adding a server to an agent. Twelve questions, grouped by what they protect.
Access
- What does the token actually grant? A read-only key and an admin key often differ by one checkbox in the vendor console. Read the scope, not the label.
- Can it be scoped to one resource? One zone, one repository, one database. If the answer is no, the blast radius is your whole account.
- Where does the credential live? Environment variables in a shell profile are readable by every process the agent spawns.
Behavior
- Does it write anything? The first question of every review we publish. A server that calls itself read-only and ships a mutation tool is mislabelled.
- What does a failed call look like? Timeout, empty result, or exception. An agent that gets an empty result will confidently report that nothing exists.
- Does it page or truncate? A tool that silently returns the first fifty rows produces answers that look complete and are not.
Cost
- How large is the tool definition? Every server you attach adds tokens to every request. A dozen servers can consume a large part of the context window before you ask anything.
- Does it fan out? Some tools issue several API calls per invocation. That is invisible in the response and visible on the bill.
Maintenance
- Who maintains it? Vendor, community, or one person. The label is not a quality judgement, but it predicts response time to a breaking API change.
- When was it last updated? A server untouched for a year is not automatically bad; an API that changed last month makes it unreliable.
- Is there a repository with issues enabled? If there is no place to report a problem, you are the only QA.
- What is the exit path? If the server disappears, can you call the API directly, or is your workflow dependent on its abstractions?
Scoring the answers
| Answers | Meaning |
|---|---|
| 10+ clear, 2 unclear | Install it, note the unknowns |
| 7–9 clear | Install read-only and observe before writing |
| Under 7 clear | Find a different server |
The scoring is deliberately coarse. The point is not a number; it is that most bad installs would have been caught by the access and cost questions alone.
None of this requires vendor cooperation. The repository, the install command, and the token scopes are all public before you install anything, which is why a ten-minute review catches most of the problems that would otherwise show up in a week.
The two questions people skip
The credential location and the tool definition size are the two most commonly ignored, and both cause the most avoidable pain.
Credentials in a shell profile leak into every spawned process, including a web app the agent starts. Tool definitions are charged on every request, so a server you use once a week still costs you tokens all week.
A worked example
Take the Cloudflare MCP: it is hosted, so there is no process to maintain; it accepts a scoped API token, so one zone is possible; observability reads only. Three questions answered quickly, and the decision is easy.
Now take a community CRM server: the token is the user's own, the tool set includes writes, and maintenance depends on one maintainer. Every answer is still obtainable — it just requires more care before the first call.
The ten-minute version
If you have one minute per server, answer these four questions and skip the rest: what token does it need, does it write, how big is its tool definition, and who maintains it.
Those four cover most of the risk. Token scope determines blast radius. Write capability determines whether a mistake is recoverable. Definition size determines ongoing cost. Maintainer determines whether the server will still work after the next API change.
The longer checklist is for servers that touch something important: infrastructure, money, customer records. For a read-only documentation server, the four questions are enough.
Frequently asked questions
How many MCP servers are too many? There is no number, but there is a signal: when tool definitions start dominating the request, you have too many. Measure the token cost of your tool list before adding another.
Should I prefer official servers? Prefer them when the alternative is an unmaintained fork, not as a category rule. A well-maintained community server beats an official one that was published for a launch and never touched.
What if I only need one tool from a large server? Look for a narrower server first. Attaching a broad server for one capability is the most common way to pay for tokens you do not use.
Last checked: 9 November 2026.
Related: MCP servers worth installing, infrastructure MCP blast radius, and what tool definitions cost.