How to evaluate an MCP server before you install it
An MCP server runs with whatever access you grant it and can read data, call APIs and — if you let it — take irreversible actions. Registries list servers; they do not vet them. Treat every server as untrusted third-party code, because that is what it is.
The checklist
| Check | What you are looking for | Red flag |
|---|---|---|
| Source | Public repo, real commit history, named maintainer | No source, or a days-old account |
| Install method | Pinned version, checksum or lockfile | npx -y latest piped straight in |
| Scopes requested | The narrowest set for its job | Filesystem root, shell, or broad OAuth scopes |
| Network egress | Only the endpoints its function needs | Calls out to an unrelated host |
| Secret handling | Reads credentials from env, never logs them | Credentials in the config file or in logs |
| Irreversible actions | Gated behind explicit confirmation | Deletes / sends / pays with no approval step |
| Dependency count | Small and auditable | A tree of transitive packages |
Practical steps
- Read the repo. If there isn't one, stop.
- Run it in a sandbox first — a container or a throwaway VM — and watch its network and filesystem activity for a session.
- Grant the minimum scope. If it asks for more than its description justifies, that is the answer.
- Pin the exact version in your config. Review the diff before you bump it.
- For anything that can write to production or spend money, require human approval on every call — configure the client to prompt, do not auto-approve.
The rule
If you cannot see the code, cannot explain why it needs each permission it asks for, and cannot revert what it does — do not install it. The convenience of an MCP server is never worth an unaudited process with your credentials.
END OF ANALYSIS