Skip to main content

Free instrument

MCP Permission Risk Checker

Tool servers are where an agent's authority becomes real: a token, a scope, a shell, an inbox. Fourteen answers about one server return an exposure level and a finding per rule the Model Context Protocol specification makes mandatory, plus the OWASP and EU AI Act entries that bound the agent behind it.

How do you tell whether an MCP server is safe to connect an agent to?

Check the rules the specification writes as must: the token was issued for this server and no other is accepted or passed upstream, the client named the server when it asked for the token, the server publishes where its authorization server is, a session id is never treated as proof of identity, and a proxy obtains consent per client. Then check what the agent behind it can do with the tools, whether it reads content written by outsiders, whether a person confirms consequential calls, and whether every call is logged and every client can be cut off at once.

1. How is the server reached?
2. How does the client authorize to it?
3. Does the server forward the client's token to an upstream API?
4. Does the server publish protected resource metadata so a client can discover its authorization server?
5. How do clients get a client id?
6. Is the server a proxy that sends users on to a third party authorization server?
7. Does the server treat a session id as proof of who is calling?
8. What can its tools do?
9. Do its tools return content written by outsiders (web pages, inbound email, tickets, issues, documents from third parties)?
10. Are its tools annotated (read only, destructive) so a client can tell them apart?
11. When does the client ask a person before a tool call?
12. Are the scopes a client can request limited to what its task needs?
13. Is every tool call recorded in a log the server operator keeps?
14. Can a client's access be revoked immediately?

13 questions left before the record can be produced.

Permission risk record

The record appears here as soon as every question on the left has an answer: an exposure level and a finding per rule, most severe first, each naming the specification section or standard it rests on.

The grounding, stated plainly

Every rule this checker scores is a sentence in a published document, each one a record on the Agent Authority Ledger with a verdict and a date: the Model Context Protocol authorization section and its July 2026 hardening, the MCP security best practices (token passthrough, the confused deputy, session hijacking, scope minimisation), RFC 8707 resource indicators, RFC 9728 protected resource metadata, RFC 7591 dynamic client registration and its deprecation, the OWASP Top 10 for LLM Applications and for Agentic Applications, the EU AI Act articles on record keeping, human oversight and deployer duties, and the ledger's absent record on revocation. The severity words are GAGE's; the requirements are theirs. What an agent that reaches this server may do is the question Know Your Agent answers; what has already gone wrong is on the Agent Incident Ledger.

Questions people ask

What does the MCP specification actually require for authorization?

That an authorization server implement OAuth 2.1, that a client name the server it wants a token for through resource indicators (RFC 8707), that a server publish protected resource metadata (RFC 9728) so a client can discover the authorization server, and that a server validate every token was issued for it as the audience and accept or pass on no other. The July 2026 revision adds issuer validation on the authorization code, binds client credentials to the issuer that minted them, and deprecates dynamic client registration.

What is token passthrough, and why is it forbidden?

A server accepting a token from a client and forwarding it upstream without validating that the token was issued to that server. The MCP security best practices name it as an anti pattern and forbid it, because the upstream API is then reached with the client's authority and every control it expected the server to apply is bypassed. This checker marks it critical.

Why does outsider content matter to a tool server?

Because an agent that reads a web page, an inbound email, a ticket or a repository issue and can then act can be instructed by that text. Prompt injection is the first entry on the OWASP list, and every documented exfiltration through an agent on the Agent Incident Ledger began with content the agent should have treated as data. A server that returns outsider content beside tools that write, send, spend or execute is scored critical unless a person confirms every call.

What are the three exposure levels?

Contained: Every normative rule the specification sets is met and the consequential tools are gated. Keep the log and the scope list current. Exposed: At least one rule the specification makes mandatory is unmet, or a consequential tool is reachable without a person in the loop. Critical: A rule whose failure hands a stolen or forged credential the whole surface is unmet: token passthrough, an unbound token, sessions as authentication, or an unauthorized remote server with consequential tools.

Does this page store what I answer?

No. The answers and the record exist only in your browser until you copy them. There is no route, no storage and no email; the only thing sent is an anonymous signal that the checker was started and finished, which carries no answers.

GAGE briefings tell you which AI regulation deadlines are coming, what they actually require of you, and when a program opens.