Last week I scanned 277 public MCP servers and wrote about the OAuth 2.1 posture. The post focused on what the authorization story looked like. It did not look at transport. This week it does, because the scanner now has four new passive checks that read the response headers and the authorization server metadata without sending a single extra request.
I re-scanned the same host list. 130 servers were reachable in both the earlier sweep and today's. Those 130 are the cohort for everything below. The number that surprised me is not small.
One check, 121 of 125 reachable servers
HEADERS-001 fires when the initialize response is missing one of four standard transport-security headers: Strict-Transport-Security on HTTPS, X-Frame-Options or a Content-Security-Policy frame-ancestors directive, X-Content-Type-Options nosniff, or a wildcard Access-Control combination.
121 of the 125 servers that were reachable this week trigger at least one of those four. That is 96.8 percent. Only 4 servers had clean transport-security headers. 5 servers were not reachable this time and could not be evaluated, which is why the denominator is 125 and not 130.
These are not checks that cost anything. Each header is one line of configuration on the reverse proxy or in the server's response code. The reason the number is this high is that nobody is used to treating an MCP endpoint as a web service that lives in a browser threat model. Agents do not live in browsers today, but the endpoint is still reachable from one and the defences cost nothing to add.
The three smaller surprises
| Check | Last week | This week |
|---|---|---|
| RESOURCE-001 (Protected Resource Metadata missing) | 0 | 6 |
| ISS-001 (RFC 9207 iss parameter not advertised) | 0 | 6 |
| AUTH-007 (invalid bearer returns wrong HTTP status) | 0 | 3 |
These three are low cost to fix and low ceiling: they catch the narrower end of what the spec requires or recommends. The reason the counts are low is that the servers this catches are a specific class. RESOURCE-001 fires only on servers that advertise OAuth and still omit the Protected Resource Metadata document. ISS-001 only on servers whose metadata is otherwise clean enough to read. AUTH-007 only on servers that bother to reject an invalid token at all. Each count is a count of near misses, not a count of broken servers.
Ten hosts lost a grade purely from the new signals
No new check fires on code these servers did not already have. The grade shift below is only the four passive signals that used to be invisible to the scanner.
| Host | Last week | This week |
|---|---|---|
| api.githubcopilot.com/mcp | A | C |
| mcp.sentry.io | A | C |
| crashstory.com/mcp | A | C |
| mcp.supabase.com/mcp | A | B |
| mcp.sentry.dev/mcp | A | B |
| mcp.deepwiki.com/mcp | A | B |
| mcp.semgrep.ai/mcp | A | B |
| mcp-server.egnyte.com/sse | A | B |
| game.spacemolt.com/mcp | A | B |
| mcp.roundtable.now/mcp | D | F |
The pattern is consistent: the grade shift is HEADERS-001 for almost everyone, plus RESOURCE-001 or AUTH-007 for the ones that drop two notches. None of these servers have broken something they had working. The scanner got a new eye.
What this is not
These numbers are not a benchmark of MCP server quality. They are a measurement of what four cheap checks catch on a public cohort today. A grade is an aggregate: a server with strong authentication and weak transport headers ends up next to a server with weak authentication and strong transport headers. The report page for each host is where the details live.
The scan also did not run the four new active checks against anyone. Those probes register clients and send crafted /authorize requests; they are safe against your own server and rude against someone else's. The headless OAuth battery is opt-in for a reason and I kept it off for this sweep.
Run your own
If your MCP server is in that list of ten, or it is not and you want to be sure:
npx -y @patchbay-nebius/agent audit https://mcp.example.com/mcpNo credentials, no flags, no account. The scan takes eight seconds and the report page is public for 90 days, which makes it easy to send to the person on your team who owns the reverse proxy.
Next sweep is next week. I will keep the same host list so the week-over-week comparison stays honest.