createmcps.com

Error

MCP OAuth: WWW-Authenticate has no scope parameter

Against MCP 2026-07-28 · verified 10 August 2026

The 401 is well-formed enough to start an OAuth flow, but it omits the one parameter that tells the client what to request. A client that guesses either over-asks — alarming the user — or under-asks and fails again after the round trip.

The error

WWW-Authenticate has no scope parameter
How often we see this:

6 of the 16 real MCP servers we probed on 2026-08-11 tripped MCP-AUT-006. That is a snapshot of hand-picked public servers, not a random sample of the ecosystem — it shows the failure is common in practice, not that a given percentage of all servers have it.

What causes it

When an MCP server requires authorization, it answers with 401 and a `WWW-Authenticate` header that bootstraps the whole flow. The `resource_metadata` parameter points at Protected Resource Metadata; the `scope` parameter says which scopes this resource actually wants.

Omitting `scope` is not fatal — the flow can still complete — which is exactly why it survives review. The cost lands on the client and the end user: with nothing to go on, a client either requests a broad scope set, producing a consent screen that asks for far more than the tool needs, or requests a minimal one and gets a second 401 after the user has already been through an authorization round trip.

This is a SHOULD-level problem, not a MUST. The validator reports it as a warning rather than a failure, and it will not stop a build unless you ask it to.

How to fix it

The fix

Name the scopes on the 401Add the `scope` parameter alongside `resource_metadata`. Space-separated, exactly the scopes a client needs for the resource it just tried to reach.
A complete MCP 401
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="mcp",
  resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
  scope="mcp:tools mcp:resources"

The fix

Keep it consistent with your resource metadata`scopes_supported` in Protected Resource Metadata is the catalogue of everything this resource understands; the `scope` parameter on a 401 is what THIS request needed. They should not contradict each other — a scope named in the header and absent from the metadata is a bug a client cannot work around.

The fix

Ask for the least that worksThe scope you advertise is the consent screen your users read. Narrow scopes are the difference between a user approving a tool and abandoning it, and MCP servers are frequently authorising access to something personal.

Rules involved

Each of these is checked against a live server, and each links to the exact sentence of the specification it comes from.

RuleWhat we checkLevelIf it fails
MCP-AUT-006WWW-Authenticate includes a scope parameterSHOULDwarn
MCP-AUT-001Unauthenticated request returns 401 with WWW-Authenticate resource_metadataMUSTfail
MCP-AUT-003PRM resource equals the canonical server URIMUSTfail

FAQ

Frequently asked

What should the WWW-Authenticate header contain for an MCP server?

At minimum a Bearer challenge and a resource_metadata parameter pointing at your Protected Resource Metadata document, so the client can discover the authorization server. It should also carry a scope parameter naming the scopes required for the resource that was refused, so the client does not have to guess.

Is a missing scope parameter a spec violation?

It is a SHOULD, not a MUST — so the validator reports it as a warning rather than a failure, and it will not fail your build unless you pass --fail-on warn. The flow still completes; the cost is a worse consent screen or an extra round trip.

What happens if a client guesses the wrong scopes?

One of two things. Guessing too broadly produces a consent screen asking for more access than the tool needs, which users refuse. Guessing too narrowly means the token comes back without sufficient scope and the next request is refused again — after the user has already completed an authorization round trip.

Check this against your own server

Point the validator at a live MCP server and it reports every rule on this page as pass, warn or fail — each linked to the exact spec sentence it comes from.

Validate a server →