auth_required
auth_required is the outcome we record when an MCP endpoint answers a connection attempt with HTTP 401 or 403. It means the address answered, was serving, and was guarding itself at the moment we asked. It is the most common result we have recorded, and it describes a working server rather than a broken one.
Updated
What does auth_required mean?
It means the server answered. A 401 or 403 is a considered response from software that is running, listening, and deciding that this particular caller may not proceed.
Compare that to an address that times out, refuses the connection, or does not resolve. Those describe an endpoint that is not there. A 401 describes one that is.
Why is it not a failure?
Because the thing being tested succeeded. The connection was established, the request was delivered, and the server exercised its own authorization logic correctly.
Treating it as a failure produces exactly the wrong ranking. It marks the production servers with real data behind them as broken while marking wide-open ones as healthy, which inverts the signal a reader wants.
How often does it happen?
More often than a successful connection. Across 82 attempts against 53 endpoints between 20 July and 5 August 2026, we recorded 40 auth_required results and 29 connections.
The remaining 13 were genuine problems: 4 protocol errors, 3 addresses that served a web page rather than an endpoint, 2 blocked by our own outbound guard, 2 unreachable, and 2 that did not resolve. Those are the outcomes that describe something wrong.
How do I fix a 401 from an MCP server?
Get the caller a token the server accepts. Four things cause almost every 401 from a server that is otherwise working:
- The client never signed in. Read the
WWW-Authenticateheader on the 401. A server following the spec names its protected resource metadata there, asresource_metadata="...", and that document says which authorization server issues its tokens. Clients such as Claude, ChatGPT and Cursor follow it and open a sign-in page; if yours shows the 401 instead, start the sign-in from the client's connector or MCP settings rather than retrying the call. - The token expired. Hosted servers issue short-lived tokens. Sign in again, or let the client refresh, and the same request goes through.
- The token was issued for a different server. The spec requires clients to name the server they want a token for (the
resourceparameter) and requires servers to reject tokens minted for anyone else [1]. A token copied from another tool or another environment is refused even though it is valid. - The header is malformed. The token goes in
Authorization: Bearer <token>on every request, not in the URL and not under another header name. An API-key server that documents its own header is the exception: use what its docs say.
If the 401 carries no WWW-Authenticate header at all, the problem is on the server side: a client following the spec has nothing to read, so it cannot start a sign-in. That is the server author's fix, covered with the full requirement list in MCP OAuth.
To see exactly what an anonymous caller gets, run your URL through our connection test. It takes an optional token, so one run shows both the 401 and whether your token turns it into a tool list.
Example
Several of the best-known hosted MCP servers answer an anonymous initialize with a 401. The specification does not oblige them to guard themselves at all: authorization is optional, and what it constrains is the shape a server uses once it decides to. Supplying a valid scoped token turns the identical request into a normal handshake and a normal tool list. The endpoint never changed; only the caller's credentials did.