MCP server review. Before it reaches a machine, not after.
Reviewing MCP servers after they are installed means asking people to remove something that already works. Reviewing them before costs less and is only workable if the review is fast enough that nobody routes around it.
- Review before installation. Removing a working server is a much harder conversation than approving one.
- Ask five questions of every server. All five are answerable in minutes for a well-documented server.
- An allowlist only works if approval is fast. A slow process produces shadow servers, not safer ones.
- For the ones already installed, start with the credential rather than the server.
Published Last reviewed
Five questions, before approval.
All five are answerable from documentation for a server worth approving. A server that cannot answer them has answered the question.
Package names are cheap and typosquatting is not hypothetical. Check the publisher against the project it claims to come from, and pin a version rather than tracking latest.
The question is not what the server asks for but what the tools you will actually use require. A server you only read with does not need a credential that can write.
A plain text token in a config file on a laptop is a different risk from a credential in the client secret storage. This answer decides what a compromised machine costs.
Tool descriptions and results become agent input. A server you do not control influences agent behaviour, which makes provenance an access question and not a preference.
A local server is reachable by whatever runs on that machine. A shared or remote one is reachable by every agent configured to use it, all acting with the same identity.
Five outcomes, not two.
A review with only approve and deny produces servers that never get submitted. The middle three are what keep it usable.
| Decision | When it fits | What it costs |
|---|---|---|
| Allowlist by server | Few servers, stable set. | Every new server waits for a review. |
| Allowlist by publisher | You trust an organisation, not a package. | A compromised publisher brings everything. |
| Allow with a scoped credential | The server is useful but broad. | Someone has to create the credential. |
| Deny and provide an alternative | The need is real, the server is not. | You owe them a replacement. |
| Allow on non-production machines only | Useful for exploration. | Needs a real boundary, not a policy line. |
How to run it. Four steps.
The second step decides whether any of the others happen.
People need to see what is already approved, otherwise every request is a new one and the queue never empties.
An allowlist with a two-day answer is used. One with a two-week answer is routed around, and then you have shadow servers instead of reviewed ones.
You rarely need to remove a server immediately. Narrowing or rotating its credential buys time and reduces the blast radius while the review happens.
What a server does changes when its version changes. A quarterly review of an unchanged server is theatre, and a changed server between reviews is the real gap.
Questions, answered.
Short answers on mcp server review.
Should we allowlist MCP servers?
Yes, if the approval is fast. An allowlist with a quick answer gets used and gives you a real inventory. One with a slow answer gets routed around, and you end up with the same servers plus no visibility, which is strictly worse than no list.
What should we ask before approving an MCP server?
Who publishes it and whether this is genuinely their package, which credential it needs and how narrow that can be, where the credential lives once configured, what the server returns into the agent context, and who can call it once it exists.
What do we do about servers already installed?
Start with the credential rather than the server. Narrowing or rotating it reduces the blast radius immediately and without an argument, and it buys the time to review properly. Removal, where it is needed at all, is easier once the access is already reduced.
Keep reading.
The pages that belong to the same picture.
See what your agents can reach. Before someone else does.
Book a demo and we walk through the access paths in an environment like yours.