An MCP security evaluation should test ten things: token audience, token passthrough, per-client consent, session handling, tool list changes, local server execution, outbound request limits, scope design, human approval, and logging. The MCP security best practices page gives the attack for each, so you can turn it into a pass or fail test.
Why test cases beat feature lists
A feature list says a product "supports MCP security." A test case says what you will do and what result you expect. When you compare approaches, the second form is much harder to answer with marketing.
The ten test cases
| # | Test | Pass looks like | Basis in the MCP security guidance |
|---|---|---|---|
| 1 | Send a token issued for another service | Rejected | Servers must not accept tokens not issued for them |
| 2 | Check whether a token is forwarded downstream unchanged | It is not | Token passthrough is called an anti-pattern |
| 3 | Register a new client and reuse an old consent | Consent asked again per client | Proxy servers need per-client consent |
| 4 | Reuse a session ID without credentials | Request refused | Sessions must not be used for authentication |
| 5 | Change a server's tool list after approval | Change is surfaced to a person | Tool list change notifications exist for this |
| 6 | Add a local server with a suspicious start command | Full command shown, approval required | Clients must show the exact command |
| 7 | Point discovery at an internal address | Blocked | Clients should block private and metadata ranges |
| 8 | Request a broad scope on first connect | Minimal scope granted, more on demand | Scope minimization guidance |
| 9 | Run a sensitive tool call | Human can see inputs and deny | Specification expects a human in the loop |
| 10 | Pull the audit record for test 9 | Identity, tool, arguments and result present | Clients should log tool usage |
Running the tests
Use a throwaway server and a throwaway client so a failed test breaks nothing real. For each test, write the expected result before you run it. If the outcome is a partial pass, record exactly what happened. A tool that blocks case 7 for IPv4 but not for an encoded address has told you something the checkbox would not.
The specification itself warns against hand-rolled IP validation, because attackers use octal, hex and IPv4-mapped IPv6 encodings that custom parsers miss. So include one encoded address among your inputs.
What these tests do not cover
They check protocol and client behaviour. They do not judge whether a given server's code is safe, or whether a model will be talked into a bad call. Pair them with a review of the server's source and dependencies, and with a look at what the model is allowed to do once a call is approved.
Treat each result as a snapshot. Servers update, so repeat the quick tests when a version changes. See also MCP server permissions for the blast radius side.
Try it yourself
Click through it at your own pace, or open it full screen.
Walk through the connection steps and decide which of the ten tests you could run at each stage.
Safeguard includes an MCP Guardrail alongside policies and gates, and the free scan is a low-effort first step for the dependency side of a server.
Quick check
Do I need all ten tests for a small team?
Start with 1, 5, 6 and 9. They cover the most common real-world risks: wrong tokens, silent tool changes, local code execution and unapproved actions.
Who should run these tests?
Someone who did not set up the server, so assumptions are not baked into the test.
Sources
Last reviewed: 19 October 2026.
