An agent points at a remote MCP server, the connection fails, and the log says 401 Unauthorized — or 403 Forbidden. The reflex is to treat it like any other 401: something is broken, a token is wrong, fix the credential. Sometimes that is exactly right. Just as often, the 401 is the server working correctly — it is supposed to challenge for a credential, and the real problem is somewhere upstream of the status code. The two cases look identical in a one-line log, and they need opposite responses. Telling them apart is most of the debugging.
This matters more for MCP than for a typical REST API, because MCP's authorization story is young and the tooling around it is younger. The spec's HTTP transport defines an OAuth 2.1 flow — the server challenges with a 401 and a WWW-Authenticate header pointing at its protected-resource metadata, the client discovers the authorization server, obtains a token, and retries. A lot of servers half-implement it, a lot of clients don't implement the discovery half at all, and a lot of endpoints sit behind a gateway that returns its own 401 before the MCP layer is ever reached. Every one of those produces the same first symptom.
A 401 Is Not a Failure — It's a State
