MCP OAuth testing without credentials, from the outside
Point MCPComp at an MCP server URL and it runs the discovery, client-compatibility, and token-trust checks a real client depends on — then grades the result. No credentials, no consent flow, no agent setup.
npx mcpcomp https://mcp.example.com/mcpOne command, ~10 seconds, exit codes honest enough for CI: 0 pass, 1 grade D, 2 grade F, 3 inconclusive.
Why MCP OAuth is hard to test
The MCP authorization spec has shipped four revisions in eighteen months and roughly tripled in size. Identity providers disagree on the primitives: some issue tokens without an aud claim, some reject the resource parameter, some omit fields the spec makes clients refuse to proceed without. A server that works in one client fails in another, and nothing on the server side logs why.
What a scan gives you
A grade you can defend
The letter counts requirement violations only — observable, citable MUSTs from the spec. Recommendations a server does not follow are reported as advisories and never decide the grade, so an A means something a reader can check.
Every finding cites the spec
Findings carry the official identifiers from the MCP conformance suite's spec-reference catalogue. A finding here and a conformance result elsewhere name the same requirement — no opinions dressed as findings.
The full flow, when you own the server
mcpcomp verify drives a complete OAuth flow end to end — machine-to-machine through the client-credentials extension, or the full interactive authorization-code flow with PKCE, state, and RFC 9207 issuer checks — using the official MCP SDK's own client, so the verdict matches what a real client does.
Frequently asked questions
Do I need credentials to test an MCP server's OAuth?
No. The passive tier makes only the unauthenticated requests any MCP client sends before it has credentials — the 401 challenge, protected-resource metadata, and authorization-server metadata. The active verify command needs credentials you provision yourself.
What does MCPComp actually check?
Thirty-one checks across discovery, client compatibility, and token trust: WWW-Authenticate challenges, metadata resolution, issuer identity, PKCE S256, registration support, HTTPS rules, scope hygiene, and more. Eighteen cite official conformance identifiers; the rest cite the underlying RFC directly.
Can this run in CI?
Yes — the exit codes are designed for it, and --json emits a machine-readable report you can diff against a committed baseline so drift fails the build.
Is a failing grade always the server's fault?
No, and the scanner says so. Redirects, dead endpoints, and servers that never demand authorization are reported as inconclusive or nothing-to-audit, not graded F — authorization is optional in MCP.