How I review an MCP server
This is the checklist behind every assessment I publish and every review I'm paid for. It's in the open because a review is only worth something if you can see what it looked for — a grade with no method behind it is a number; a method you can read is a standard.
It runs in two tiers. The first is the basics — the things a serious MCP server now gets right, and most of the good ones do. The second is the hardening: a set of checks, all grounded in the current spec, that almost nobody has done yet, including servers that are excellent on the basics. That second tier is where a review earns its keep, and it's the honest reason a well-built server still comes back with findings. They aren't nitpicks. They're the difference between a server that declares itself safe and one that stays safe under a determined agent.
Tier one — the basics
Necessary, and increasingly common. A server that misses these isn't early, it's behind.
1 · Tool annotations. Does every tool declare readOnlyHint, destructiveHint, openWorldHint — correctly? It's the only machine-readable way a client knows what's safe to run unattended.
2 · Destructive operations labelled. Is everything that deletes, writes, sends or spends marked destructive, so a host can gate it?
3 · Path handling. A root allowlist that denies by default; a symlink check before the path resolves, not after; identifiers rather than raw paths.
4 · Query safety. Is "read-only" enforced by parsing the SQL, not pattern-matching it? Multiple statements refused? Writes-in-a-CTE caught?
5 · Untrusted content. Does content read from the web, a database or disk come back marked untrusted, or arrive in the same channel as the user's instructions?
6 · Access model. Least privilege: the agent doesn't choose its own scope, and an empty configuration denies everything rather than defaulting to the world.
7 · Tests & CI. A test behind each dangerous path, and CI actually running them. A guard with no CI is one careless merge from gone.
Tier two — the hardening almost nobody has done
This is the frontier. Each is real, each is in the spec or the SDK's own gaps, and each is missing from the large majority of servers I read — good ones included. Finding these is the point of paying someone to look.
8 · Confirmation, not just a label. A destructiveHint warns that a tool deletes; it doesn't stop it. The 2026-07-28 spec added elicitation so a server can require an explicit confirmation before it acts. Almost no server uses it — most rely on the host to notice the hint and prompt, which most hosts don't.
9 · Approval that can't be replayed. If a server has a confirm/approve step, is the approval consumed when it's used, or can the same token authorise a second action? The SDK binds and expires approval state but does not consume it — closing that gap is the server's job, and one most haven't.
10 · Re-validation at the moment of action. Is a target re-checked against the filesystem or database at the instant of the destructive act, or trusted from an earlier scan? The gap between scanning and acting — with an agent thinking in between — is where a directory becomes a symlink and a safe target becomes a dangerous one.
11 · Defense in depth. When the first guard fails, is there a second? A read-only SQL guard backed by a database login that also lacks write permission; a path allowlist backed by a sandbox. One layer is a single point of failure however careful it is.
12 · Blast radius. Are expensive or bulk-destructive operations bounded — a dry-run default, a cap on how much one call can delete or spend — or can a single tool call do unlimited damage if the model gets it wrong?
What this means for a review
Most serious servers pass tier one. Almost none pass all of tier two — which is not a criticism, it's the state of a protocol that's barely a year old and moving fast. So an honest assessment of a good server reads like this: excellent on the basics, and here is the specific hardening it hasn't reached yet. That gap is exactly what a review exists to find and close — and it's the thing an enterprise customer's security team is starting to ask about.
What you get
A paid review runs both tiers against the whole server and writes up what it finds — each finding with a test that proves it, each safe area noted as checked rather than skipped. A document you can forward to whoever asked whether anyone had looked.
See it applied.
The field notes run this across thirteen servers; the assessments apply it one server at a time, mine and others'. For a review of yours: lesliekadenge@gmail.com.
The method tracks the protocol — the 2026-07-28 spec's elicitation reshaped the confirmation checks, and the annotation expectations hardened over the year. Corrections and additions welcome.