Installing an MCP server feels like installing a browser extension. Two clicks, immediate usefulness, no ceremony. It is much closer to running someone else code inside your production environment with a copy of your credentials.
The public registry passed roughly 2,000 entries within months of launching. That is a supply chain, and it deserves supply chain habits.
The Numbers Worth Knowing
An academic study of 1,899 MCP servers found roughly 5.5% showing signs of tool poisoning, where a server embeds adversarial instructions in its tool descriptions. A separate scan of 1,808 servers reported that 66% had security issues of some kind.
Most of that is sloppiness rather than malice, which is cold comfort. An over-permissioned server built by a well-meaning developer leaks data just as effectively as a hostile one.
The Ten-Minute Review
- Read every tool description in full. Not the readme, the actual descriptions the model will consume. This is where poisoning lives, and it is the step everyone skips.
- Check what credentials it requests. Compare the scope requested against the job you want done. Anything broader is a no until justified.
- Find out where data goes. Does the server call out to a third party? Many wrap an API you did not realise was in the path.
- Look at maintenance signals. Last commit, open issues, whether the maintainer responds. An abandoned server is a future vulnerability with your credentials attached.
- Count the tools. Forty tools is a red flag for both security and accuracy. Prefer narrow servers.
- Pin the version. Never track latest for anything holding credentials.
The Rule People Get Wrong
Approval at install time is not approval forever. A server can change a tool definition after you approved it, and the model will read the new description on the next call without asking anyone.
So treat description changes like dependency updates. Pin versions, diff on upgrade, and re-read the descriptions. If your tooling cannot show you what changed, that is your answer about whether to upgrade.
Trust Tiers That Work in Practice
| Tier | Example | Treatment |
|---|---|---|
| First party | Server for a system you own | Standard code review |
| Vendor official | Published by the SaaS vendor | Review scopes, then trust the vendor |
| Popular community | Widely used, active maintainer | Full review, pin version, read-only first |
| Everything else | Anything you cannot verify | Do not install on production credentials |
What to Do at Organisation Scale
Individual review does not scale past a few dozen people. At that point, maintain an internal approved list, route access through a gateway so unregistered servers are unreachable, and assign each approved server an owner with a review date.
Then check the registry entry against the actual source. A registry listing is a distribution channel, not an endorsement, and the gap between the two is where trouble lives.
Conclusion
Read the tool descriptions, compare requested scopes against the actual task, pin the version, and start read-only. At organisation scale, keep an approved list with named owners and make unregistered servers unreachable. This is dependency management with a shorter feedback loop and a higher blast radius, and the teams who get burned will be the ones who treated it as installing an app.
Frequently Asked Questions
Are official vendor servers safe to install without review?
Review the scopes at minimum. The common problem with official servers is not malice, it is a well-built server requesting far broader access than your use case needs.
How do I detect tool poisoning?
Read the descriptions with the question would I be comfortable if a stranger wrote this instruction into my agent prompt. Because that is exactly what a tool description is.
What if a server we depend on is abandoned?
Fork it, pin it, or replace it. An unmaintained server holding live credentials is an accepted risk, and it should be an explicitly accepted one with a name against it.