Zuplo

Discovery

How a client finds out where to authenticate, starting from a 401 it did not expect.

Protected resource metadata

PRM A JSON document, published by a protected resource, that names the authorization servers able to issue tokens for it. #

A JSON document, published by a protected resource, that names the authorization servers able to issue tokens for it. RFC 9728 defines the document and the /.well-known/oauth-protected-resource URI it is served from. An MCP server must implement it, and an MCP client must use it to find the authorization server.

Where you meet it

It is the document a client fetches after a 401, using the resource_metadata URI from the WWW-Authenticate challenge. The well-known string is inserted between the host and the path, so an endpoint at https://example.com/public/mcp publishes metadata at https://example.com/.well-known/oauth-protected-resource/public/mcp. When the client reached the document through a resource_metadata URI, the resource value inside it must be identical to the URL the client actually dialed, and a client must not use the data if the two differ.

Also written: PRM · protected resource metadata · RFC 9728 · oauth-protected-resource · resource metadata

Source: RFC 9728, Section 3 MCP 2026-07-28: Authorization Server Discovery
On this site: 401 without a WWW-Authenticate header OAuth 2.1 authentication for MCP servers
Read next: ASM WWW-Authenticate Resource indicators

Authorization server metadata

ASM A JSON document, published by an authorization server, that lists its endpoints and capabilities: issuer, authorization_endpoint, token_endpoint, scopes_supported, and which registration mechanisms it supports. #

A JSON document, published by an authorization server, that lists its endpoints and capabilities: issuer, authorization_endpoint, token_endpoint, scopes_supported, and which registration mechanisms it supports. RFC 8414 defines it and its well-known URI. An MCP authorization server must publish either this document or an OpenID Connect discovery document, and MCP clients must support both.

Where you meet it

A client reads it after protected resource metadata told it which authorization server to use. It is a different document from protected resource metadata, published by a different party, and confusing the two is a common reason a discovery chain looks configured but fails. The issuer in the document must be identical to the issuer identifier used to build the well-known URL, and a client must not use metadata where the two differ.

Also written: authorization server metadata · RFC 8414 · oauth-authorization-server · AS metadata · ASM

Source: RFC 8414, Section 3 MCP 2026-07-28: Authorization Server Metadata Discovery
On this site: Failed to fetch authorization server metadata
Read next: PRM DCR CIMD

WWW-Authenticate

The HTTP response header field a server uses to challenge a client for credentials, defined by RFC 9110 and given its Bearer-scheme parameters by RFC 6750. #

The HTTP response header field a server uses to challenge a client for credentials, defined by RFC 9110 and given its Bearer-scheme parameters by RFC 6750. In MCP it carries the resource_metadata parameter pointing at the server's protected resource metadata document, and the MCP specification says servers should also include a scope parameter naming the scopes the request needs.

Where you meet it

It is the one header that turns an opaque 401 into a discoverable login. A server that returns 401 with no challenge leaves every compliant client with nothing to act on, which is the highest-traffic failure in the error library.

Also written: WWW-Authenticate · www authenticate header · 401 challenge · resource_metadata · Bearer challenge

Source: RFC 9110, Section 11.6.1 MCP 2026-07-28: Scope Selection Strategy
On this site: 401 without a WWW-Authenticate header 302 redirect instead of 401
Read next: PRM Scope

server/discover

New in 2026-07-28 A method that returns a server's supported protocol versions, capabilities, and identity in a single request. #

A method that returns a server's supported protocol versions, capabilities, and identity in a single request. Servers must implement it. Clients may call it before anything else, but are not required to: a client can send any request and handle an UnsupportedProtocolVersionError instead.

Added in this revision, and servers must implement it. It replaces the up-front capability exchange the removed initialize handshake used to perform.

Where you meet it

On stdio it is also the backward-compatibility probe — a client that must work against both modern and handshake-era servers sends server/discover first, and treats any error that is not a recognized modern error as evidence of a legacy server.

Also written: server/discover · DiscoverResult · mcp discover method · supportedVersions

Source: MCP 2026-07-28: server/discover
Read next: initialize handshake MCP-Protocol-Version _meta