Join the waitlist→

///// Research · 2026-11-03 · 3 min read

1 in 9 MCP servers that use sign-in break before a login page

We checked 1,000 servers from the official MCP Registry. Of those that use sign-in, 11% fail before a user ever sees a login page, most often at the first step.

When you add a remote MCP server to ChatGPT, Claude, Cursor, Codex or Gemini, the host does a short dance before you ever see a login page. It calls the server without credentials, expects a 401, follows the challenge to the server's protected-resource metadata, finds the authorization server, checks that it supports PKCE, and gets itself a client. If any step breaks, the host shows a generic error, or nothing at all.

We wanted to know how often that dance fails in the wild, so we checked 1,000 servers from the official MCP Registry.

What we found

Of 1,000 randomly sampled remote MCP servers on their own domains:

  • 38% use sign-in. 53% are open and answer without credentials. 6% are dead.
  • 11% of the servers that use sign-in break before a user ever sees a login page. That's about 1 in 9. The server's owner may never hear about it.
  • 3% answer 401 and point nowhere. There's no challenge telling the host where to look, and nothing at the well-known locations the MCP spec says to try next.
  • 6% are listed in the registry but dead. The domain no longer resolves, the certificate fails, or the endpoint returns 404 or 5xx.

The margin of error is about ±3 points on each number.

Where sign-in breaks

| What breaks | Share of broken servers | | ----------------------------------------------------------------------------------------- | ----------------------- | | 401 with no usable metadata, in the challenge or at the fallback | 67% | | The protected-resource document is missing or lists no HTTPS authorization server | 12% | | The authorization server's metadata is missing, invalid or too slow | 12% | | No way for a host to get a client (no dynamic registration, no client metadata documents) | 9% |

They stay broken because nothing tells the owner. Your own dashboards stay green: the server is up, and your own client, which already has a token, works fine.

A further 13 servers work only because the host follows the spec's fallback. Hosts that read just the 401 challenge can't sign in to them.

What good looks like

An unauthenticated request to your MCP endpoint should return:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://example.com/.well-known/oauth-protected-resource/mcp"

That document lists your authorization server:

{
  "resource": "https://example.com/mcp",
  "authorization_servers": ["https://auth.example.com"]
}

The authorization server's metadata, at /.well-known/oauth-authorization-server, must include:

  • authorization and token endpoints;
  • "code_challenge_methods_supported": ["S256"];
  • either a registration_endpoint or "client_id_metadata_document_supported": true.

If your proxy blocks dot-paths, make sure /.well-known/ gets through. A missing file should return 404, not your proxy's 403 page.

Check your own server

npx backwatch your-site.com

Backwatch runs the same probe we used for this study. It also checks:

  • whether agents can read your site: llms.txt, Markdown for real pages, the agent budget;
  • whether they can find your server: /.well-known discovery and server cards;
  • whether you're listed in the MCP Registry.

Every failure comes with a fix prompt you can paste into Claude Code, Codex or Cursor. Add --ci --baseline .backwatch.json to a GitHub Action, and a regression fails the build instead of reaching your users.

It's MIT-licensed and sends no telemetry. It doesn't sign in, and it doesn't register clients unless you ask it to, for your own server, with --register.

How we measured

  • Frame: the official MCP Registry on 3 November 2026. That's 36,762 remote servers over HTTPS, 21,320 of them on their own domain. Servers on shared platform hosts were excluded.
  • Sample: 1,000 servers in a seeded random sample, one per domain.
  • Requests: one anonymous request per server, plus the metadata reads a host would make. The probe sent a declared User-Agent, used no credentials and created nothing.
  • Probe: it follows the MCP authorization spec, including the well-known fallback, all three metadata locations, redirects, and issuers with a trailing slash. A host that implements less of the spec fails more often than this.

Limits:

  • Some servers that answer 401 with nowhere to go may expect a pasted API key instead of OAuth. Claude Code, Cursor and Codex can connect that way; ChatGPT and Claude.ai connectors can't.
  • We checked discovery, not a completed login.
  • A single request per server means a brief outage counts as dead.

All posts→