A practical security scorecard for evaluating an MCP server: source trust, least privilege, secrets, OAuth, version pinning, egress, and monitoring.
Seventeen controls across five areas, weighted by severity, with a verdict that turns red the moment any critical control is unmet. Tick what you have verified, expand any item to read why it matters, and copy a plain-text report of every checked and unchecked control. Everything runs in your browser and nothing is stored.
Two honest limits up front. This checklist does not inspect anything — it does not connect to a server, read its manifest, or scan its code. It is a structured prompt for your own review, and the answers are only as good as the checking you do behind them. And a full score is a hardening aid, not a guarantee: an MCP server that was safe when you installed it can change behaviour on any update, which is why one of the seventeen items is about re-reviewing.
The Model Context Protocol connects an AI client to external tools and data through servers that expose callable tools and readable resources. Local servers typically run as a process on your machine over stdio; remote servers are reached over HTTP. Either way, the server runs with real privileges — your filesystem, your API tokens, your database — and the thing deciding when to call it is a language model reading text it did not write.
That combination produces failure modes that a generic dependency review misses:
| Section | Items | Question it answers |
|---|---|---|
| Source & Trust | 4 | Where did this server come from and can the publisher be trusted? |
| Permissions & Scope | 4 | How much can it reach, and does it follow least privilege? |
| Secrets & Auth | 3 | How are credentials stored and how does it authenticate? |
| Runtime & Network | 3 | How does it execute and what can it talk to? |
| Monitoring & Governance | 3 | How would you detect and respond to abuse over time? |
Source & Trust asks whether the publisher and exact package name are vetted, whether the version is pinned and verified rather than tracking latest, whether source is available and has been reviewed, and whether the dependency tree has been considered. Two attack shapes sit behind these: typosquatted package names that ship malware the moment a client launches them, and rug-pulls where a package that has been safe for months pushes a malicious update.
Permissions & Scope is where most of the real risk reduction lives. It asks whether the tool scope is genuinely least-privilege, whether read-only mode is used where writes are not needed, whether destructive actions sit behind explicit human approval rather than auto-approve, and whether tools and resources are allowlisted rather than denylisted. The allowlist item has a specific purpose: when a server adds new tools in an update, a denylist admits them by default and an allowlist blocks them until reviewed.
Secrets & Auth covers plaintext credentials in configuration files — keys committed in .mcp.json or claude_desktop_config.json leak through dotfile repositories and backups — scoped, individually revocable tokens per server instead of reused admin keys, and, for remote servers, a review of token audience and consent flow against confused-deputy risk.
Runtime & Network asks whether the server runs sandboxed in a container, VM or restricted user rather than your main account, whether outbound network access is restricted to known endpoints, and whether remote endpoints use TLS with certificate validation. Egress restriction is the control that turns a compromised server from a data-exfiltration event into a contained one.
Monitoring & Governance covers audit-logging every tool invocation and its arguments, re-reviewing the server on each version bump, and naming an accountable owner for the integration — the item that stops a server installed for one experiment from becoming a permanent, unmonitored standing risk.
Each item carries a severity, and each severity carries a weight. Five items are critical, seven are high and five are medium, giving a maximum of 34 points.
| Severity | Weight | Items | Points available |
|---|---|---|---|
| Critical | 3 | 5 | 15 |
| High | 2 | 7 | 14 |
| Medium | 1 | 5 | 5 |
| Maximum weighted score | 34 | ||
The displayed percentage is your accumulated weight divided by 34, rounded. The verdict then applies three bands, with one override:
The unmet-critical override is the important part of that logic: it fires regardless of percentage. Tick sixteen of the seventeen items and leave one critical control unmet and the verdict is still High risk, on a weighted score in the nineties. That is intended. A pinned, sandboxed, audit-logged server that auto-approves destructive tools is not a moderately risky server; it is one bad tool result away from a bad day.
Two worked figures. Ticking all five critical and all seven high items but no medium ones gives 15 + 14 = 29 points, which is 85% of 34 and lands exactly on the Reasonable threshold. Ticking all five critical plus three high items gives 15 + 6 = 21 points, or 62%, which reads Caution. Ticking every medium item and nothing else gives 5 points — 15% — and High risk both because the score is below 50% and because five critical controls are unmet.
Because any one of these unmet forces a High risk verdict, they are the shortest useful version of the whole list:
~/.ssh or a password manager exportThree of those are about what the server can do rather than what it is, which is the right emphasis. You cannot fully verify the intent of code you did not write, but you can bound what happens if you are wrong about it.
Assess one server at a time. The controls are per-integration: scope, credentials, sandboxing and ownership are all decisions you make separately for each server in your configuration, and a combined score across five servers hides the loosest one. If you run several, run the checklist several times and keep the reports.
Each item can be expanded to read the reasoning behind it, which is worth doing on first use — the explanations are what turn an abstract control into something you can go and verify. Check all and Reset sit next to the verdict; Check all is there to explore how the scoring behaves, not to record an assessment. The progress bar tracks the weighted percentage rather than the raw count, so it moves further when you tick a critical item than a medium one.
Copy report puts a plain-text summary on your clipboard: the verdict, controls met out of 17, the weighted score with its points out of 34, a count of unresolved critical controls when there are any, and then every section with each item marked [x] or [ ] alongside its severity label. It closes with a reminder that a high score reduces rather than eliminates risk.
That copy action is the only way to keep the result. There is no download button, no account and no autosave, so reloading the page clears every tick. Paste the report into the ticket, runbook or pull request where the server is being approved — the unchecked lines are as useful as the checked ones, since they record what you accepted rather than fixed.
Not every server needs every control. A read-only local server pointed at one directory, pinned to a commit, with no credentials at all, is genuinely low risk with several items unticked, and forcing it to 100% is theatre. The controls that carry weight for a reason are the ones that bound damage: least privilege, human approval on destructive tools, no plaintext secrets, restricted egress, and a log of what was called.
Re-run the checklist on every version bump. A server's tool descriptions, permissions and dependencies can all change in an update, and the model reads the new descriptions as instructions the first time it connects.