The state of MCP auth, November 2026: I scanned 25 public servers

MCP (Model Context Protocol) has an auth story on paper: OAuth 2.1 with PKCE, dynamic client registration, resource indicators per RFC 8707. In practice I kept running into servers that were missing most of it. So I spent a week building patchbay audit, a free CLI that pokes an MCP server and reports what it finds. Then I pointed it at 25 public endpoints.

The numbers

25 servers scanned on 2026-11-02. All publicly listed in community directories or vendor docs. URL list in the repo.

Three servers initially triggered critical findings. One (Chainflip's broker MCP) came back within hours documenting their public-by-design broker pattern: tools are intentionally no-auth because the actual value transfer is signed on-chain by the user. Downgraded to the same bucket I use for DeepWiki. Two embargoed findings remain under a 90-day embargo.

Public-by-design servers like DeepWiki and Chainflip are now flagged as info, public read-only or user-signed pattern rather than critical. That distinction matters more than it sounds: the first version of my tool called DeepWiki "critical no auth required", which would have made the whole write-up indefensible on day one.

What the tool actually does

patchbay audit <url> runs 13 checks grouped roughly like this:

Auth presence (AUTH-001, AUTH-002). Does the server accept tools/list without credentials? If yes, do any tool names look mutating (create / delete / send / execute / start-...)? Critical only when both are true.

OAuth metadata completeness (AUTH-003 / 004 / 005). If the server serves /.well-known/oauth-authorization-server, we read it and check for PKCE S256 advertisement, resource indicators, and a dynamic client registration endpoint.

Scopes (SCOPE-001, SCOPE-002). If the server advertises OAuth, do its tools declare per-tool scopes? Do write and read tools share a scope (so revoking write access also revokes reads)?

Secrets and transport (SECRET-001, SECRET-002, TRANSPORT-001, TRANSPORT-002, REDIRECT-001). Hardcoded sk-... / ghp_... / AKIA... in source files (skipping test fixtures). Remote-mode checks plain HTTP, spoofed Origin, loopback redirect-uri handling.

Honest probe failures (PROBE-001). If the probe can't learn anything (auth-walled, unknown transport, no response), we say so explicitly instead of returning "0 findings, all clean". That silent-false-negative trap is real when scanning diverse servers.

Run it:

npx -y @patchbay-nebius/agent audit https://mcp.example.com/mcp
npx -y @patchbay-nebius/agent audit ./my-mcp-server --json
npx -y @patchbay-nebius/agent audit ./my-mcp-server --pr-draft --out PATCHBAY_AUDIT.md

--ci makes it exit non-zero on critical / high so your GitHub Action fails the build. A drop-in GitHub Action posts the markdown findings as a PR comment and uploads SARIF to GitHub Code Scanning.

What I think is actually going on
The MCP 2025-03-26 Streamable HTTP spec is new enough that most server implementations are catching up to it. Vendors that already have working OAuth (Linear, Notion, Supabase) tend to require auth but not necessarily serve the MCP-specific discovery documents.

The servers to worry about are the public ones with mutating tools and no documented reason for being public. Startups and solo projects shipping MCP endpoints that look like read-only wiki queries but include create_... or update_... tools in the list.

If you’re building an MCP server right now, the fastest wins are:

Serve /.well-known/oauth-protected-resource so clients can discover your auth server
Advertise code_challenge_methods_supported: ["S256"] and resource_indicators_supported: true in your authorization server metadata
Give each tool its own scope and reject calls whose token lacks it
Try it
npx -y @patchbay-nebius/agent audit
Repo (MIT): GodSmasher/patchbay. No tracking, no backend, no account. Just a CLI.

False-positive reports are the most useful feedback right now. The severity recalibration between first and second version came entirely from running the tool on known-good servers.

Originally published at patchbay-mcp.dev/blog.