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

1. Read the repo. If there isn't one, stop.
2. Run it in a sandbox first — a container or a throwaway VM — and watch its network and filesystem activity for a session.
3. Grant the minimum scope. If it asks for more than its description justifies, that is the answer.
4. Pin the exact version in your config. Review the diff before you bump it.
5. 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.