To test MCP server coverage, set up two throwaway MCP servers, one local and one remote, connect them to a test client, and see whether the security tool lists each server, the tools it exposes and the access it holds. If it only reports packages, it covers dependencies, not MCP.
What coverage means here
An MCP server is a program that exposes tools to an AI client. The MCP specification describes tools as callable functions a model can invoke, and says servers must validate inputs, apply access controls, rate limit calls and sanitize outputs. That makes the server both a dependency and a live interface.
So coverage has two halves. The first is inventory: which servers exist, where they run, who installed them. The second is behavior: what each tool can do and what credentials it uses. Many products do the first half and describe it as the second.
Set up the test
- Pick one local server that runs as a process on a developer machine.
- Pick one remote server reached over HTTP.
- Give the local one access to a scratch folder with dummy files.
- Give the remote one a throwaway account with no real data.
- Connect both to a test client on one machine.
Use dummy data throughout. You are testing visibility, not attacking anything.
What to ask the tool to show
| Question | Good evidence |
|---|---|
| Is each server listed? | Name, transport, location and who configured it |
| Are its tools listed? | Tool names and descriptions from the server |
| What can it reach? | Folders, accounts or scopes, not just a package name |
| Who approved it? | An approval record with a date |
| What changed? | A diff when the server updates its tools |
The last row matters. The specification lets servers notify clients when the tool list changes, and it tells clients to treat tool annotations as untrusted unless they come from a trusted server. A tool that cannot tell you a server's tools changed after approval is missing something you will want later.
The authorization check
For remote servers, ask how the tool reasons about tokens. The MCP authorization text says a server must validate that access tokens were issued for it as the intended audience, and must not pass through tokens it received to upstream APIs. You do not need a product to test this on every server, but you should ask whether it helps you notice a server that violates it. For background, see MCP token passthrough explained.
Try it yourself
The demo walks through setting up an MCP server with Safeguard. Watch how the server is registered and what information is captured at setup, then compare it with the table above.
Click through it at your own pace, or open it full screen.
Scoring it
Give each row a score of zero, one or two. Zero means not shown, one means shown with manual work, two means shown natively. Add a note on how you confirmed it. Two candidates with the same total can differ greatly in the rows you care about, so look at rows, not sums.
Safeguard includes MCP Guardrail and asset discovery as GA capabilities. As with any vendor, run the test above on your own setup before relying on a description.
Quick check
Is an allowlist of MCP packages enough?
It is a start. It does not show what tools a server exposes, what it can reach, or whether it changed after approval.
Should the test use real credentials?
No. Use throwaway accounts and dummy files. You are checking visibility, not exposing real data.
Sources
- Model Context Protocol, Tools specification (2025-06-18)
- Model Context Protocol, Authorization specification (2025-06-18)
Last reviewed: 19 October 2026.
