MCP Server Auditor

This auditor talks to the live Model Context Protocol server. It does not re-audit Server Card document structure — that belongs to the MCP Server Card Auditor. Rule 301 is the only card cross-check: advertised remotes[].supportedProtocolVersions versus the live handshake. Real remote MCP servers are almost always gated by OAuth 2.0. This auditor has no way to obtain a bearer token, so when a candidate endpoint returns 401 Unauthorized it audits the compliance of the challenge and discovery metadata instead of treating the server as unreachable.

​

How it works

Users most often give a project’s main domain rather than the exact MCP endpoint path, so the auditor builds a list of candidate endpoints before probing:

1. Discover endpoints — uses /.well-known/ai-catalog.json as a link source for Server Card remotes, then /.well-known/mcp/server-card.json and /mcp/server-card. Reads the official remotes[].url array when present, and falls back to a top-level url field for real-world cards that predate or diverge from that schema (e.g. Resend’s). Always adds the given URL itself and {origin}/mcp as fallbacks, so an exact endpoint URL (e.g. .../v2/mcp) still works even when no card is published.
2. Negotiate — for each candidate in turn, POST server/discover at the newest known protocol date (2026-07-28), with the MCP-Protocol-Version/Mcp-Method headers and _meta fields the live spec requires. On a 400 UnsupportedProtocolVersionError, retries once with the newest mutually-known date from the server’s advertised supported list — this is the actual protocol-version negotiation the server runs, not an assumption.
3. Legacy fallback — if server/discover is not implemented (HTTP 404/405, an unrecognized 400 body, or a -32601 Method not found error), falls back to a legacy initialize handshake at protocolVersion 2025-11-25. Accepts application/json or a single text/event-stream event.
4. OAuth challenge — a 401 response from any candidate stops the search and short-circuits into OAuth compliance evaluation instead of the handshake path: does WWW-Authenticate carry a compliant Bearer resource_metadata challenge (RFC 9728 §5.1), does that Protected Resource Metadata document validate, does its authorization server publish valid metadata (RFC 8414, falling back to OIDC discovery) over HTTPS, and does that metadata advertise Dynamic Client Registration (registration_endpoint, RFC 7591) and PKCE S256 so clients can actually connect. A candidate that fails outright (no response, non-2xx/non-401 status) is skipped in favor of the next candidate; when none produced a handshake or a 401, a candidate that answered 403/407 is reported as a blocked gateway (403), and the two /.well-known/oauth-* documents are probed directly at the origin so one blocked independently of the endpoint is still caught (330).
5. Dispatch — a successful discover result is audited by the 2026-07-28 class. An initialize result is audited by the class for the negotiated protocolVersion. Unknown dates fail 402 and skip definition rules.
6. Aggregate — ERROR (500) wins, then auditor FAILs (400/401/402/403 on the handshake path, 427–430 on the OAuth path), then that version’s FAILs, then WARNINGs (including the OAuth 330/331/332). If every rule passes, the audit is SUCCESS (200) — either a working handshake or a spec-compliant OAuth challenge.
7. Specification pins — every run emits 37A-McpServerAuditor-100 through 104 (one per MCP protocol date) and 105 (MCP Authorization). Those checks do not change overall status.

​

What it audits

Every row maps to one checkRule* method and one CheckCode. Definition rules (410–426, 310–321) run only for the negotiated protocol date, on the handshake path. OAuth rules (427–430, plus the 331/332 warnings) run on the 401 challenge path. 403 (blocked gateway) and 330 (blocked origin discovery document) run on the no-handshake/no-401 path. Pins 100–105 are emitted on every run, including fetch errors. Skip 301 when no Server Card was found. CheckCode suffixes use status ranges: 100–199 information, 200 success, 300–399 warning, 400–499 fail, 500–599 error.

​

Output documentation

​

Risks and considerations

​

AI clients cannot guess the handshake

• Without a reachable MCP endpoint, agents cannot list tools or complete a session against the site.
• A server that only speaks an unknown protocol date will be skipped by clients that implement the five dates this auditor pins.

​

Card and runtime can drift

• A Server Card that advertises different supportedProtocolVersions than the live handshake steers clients toward a connection that will fail or negotiate down.
• Keep remotes[].url and protocol dates in the card aligned with the running server.

​

Most remote servers require OAuth, and clients must discover it correctly

• MCP Authorization is optional per spec, but nearly every production remote MCP server (this auditor’s own, Resend’s, Atlassian’s) enforces it via a 401 challenge.
• A 401 without a compliant WWW-Authenticate: Bearer resource_metadata="..." header leaves clients with no standard way to find where to authenticate.
• Protected Resource Metadata and Authorization Server Metadata that are unreachable, malformed, or served over plain HTTP block or downgrade every client’s authorization flow, not just this auditor’s.

​

A proxy or gateway in front can block the handshake or discovery independently

• When the MCP endpoint sits behind a reverse proxy, API gateway, or WAF, that layer can reject unauthenticated requests with 403/407 instead of letting the server answer with a 401 challenge (403) — the endpoint looks dead to every client even though the server is healthy. This is exactly how a missing gateway-injected header took 37 Audits’ own MCP offline: clients saw 403 and reported registration failures.
• The MCP endpoint and each /.well-known/oauth-* document are often separate gateway routes that can fail independently, so a discovery document can stay blocked (330) after the endpoint is fixed. This auditor probes those documents directly at the origin, the way a client does, rather than only following the 401 challenge header.
• A compliant challenge still is not enough to connect: clients such as Claude.ai rely on Dynamic Client Registration (registration_endpoint, 331) and PKCE S256 (332); a server that omits either leaves those clients unable to register or to complete the authorization code flow.

​

Older initialize vs server/discover

• Protocol 2026-07-28 replaces initialize with server/discover and requires cacheScope, ttlMs, resultType, and supportedVersions.
• Staying on an initialize-only date (300) works for older clients but misses discover-based metadata and caching hints.