Discovery is identity-sensitive. Treat paths, trailing slashes, ports, and origins deliberately. A metadata document that points at the wrong resource can create audience failures even when every endpoint returns 200.
Minimal shape
{
"resource": "https://mcp.example.com/mcp",
"authorization_servers": ["https://auth.example.com"],
"scopes_supported": ["mcp:read", "mcp:write"],
"bearer_methods_supported": ["header"]
}Fields to review
- resource: the protected resource identifier used consistently during authorization and token validation.
- authorization_servers: issuer locations the resource trusts.
- scopes_supported: capabilities meaningful to this resource; keep them narrow.
- bearer_methods_supported: prefer Authorization headers instead of query parameters.
Common MCP discovery failures
The server advertises an issuer different from the authorization server metadata; the resource value omits the MCP path; a reverse proxy changes scheme or host; the well-known route is placed under the wrong path; or the token is issued for a different audience.
What the browser validator checks
It compares the resource URL, protected resource metadata, and authorization server metadata without fetching or transmitting either document. Live response headers, redirects, CORS, status codes, and token validation remain separate tests.