Surface unreachable Protected Resource Metadata instead of falling back to legacy discovery

[koic]

Motivation and Context

Flow#locate_authorization_server treated every failure to fetch Protected Resource Metadata as "the server publishes none" and took the legacy 2025-03-26 path, where the MCP server's origin becomes the authorization base URL. A request that never reached the server, or a 5xx or 429, says nothing about what the server publishes, so a transient failure moved the flow to a different authorization server, discarded client information and tokens bound to the real one on the way, and surfaced as an unrelated error, such as a failed registration at the origin, rather than as the fetch failure itself. The comment claimed both reference SDKs behave that way, which is not so: outside browsers the TypeScript SDK propagates network errors from discovery, and the Python SDK propagates them and refuses the legacy path after a 5xx or 429 from any candidate.

Discovery now keeps trying candidate URLs until one serves a JSON object and classifies the outcome once they are exhausted. Like the Python SDK, it remembers a 5xx or 429 from any candidate before deciding on the legacy path; moving on to the next candidate after a network error is what the loop already did. MetadataNotPublishedError (a 4xx other than 429, or a body that is not a JSON object) is the only failure that selects the legacy path; MetadataUnreachableError (a network error, or a 5xx or 429, from any candidate) is raised instead. Both subclass AuthorizationError, so callers rescuing that class keep working, and MCP::Client::HTTP still falls back from a failed refresh to the full flow, which repeats discovery and raises the same way unless the server has recovered. A body over the response cap is refused outright with a plain AuthorizationError, as it already was on the modern path. The message lists every candidate's failure, with the URL stripped of userinfo, query and fragment and cut to a fixed length, but otherwise spelled as requested, and with transport and parser messages bounded, as token endpoint diagnostics already are. The default legacy endpoints for an origin whose own metadata document is absent are unchanged.

How Has This Been Tested?

New tests in test/mcp/client/oauth/flow_test.rb and test/mcp/client/oauth/discovery_test.rb. Against the library before this change, discovery in the scenarios these tests set up took the legacy path instead of raising.

Breaking Changes

When no Protected Resource Metadata candidate serves a JSON object, a request that failed to reach the server, or returned a 5xx or 429, now raises instead of attempting the legacy 2025-03-26 discovery at the MCP server's origin, and a Protected Resource Metadata body over the response cap is refused instead of triggering that fallback.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed