Preserve paths when building PRM URL, per specification.

[jaredhanson]

Preserves paths and query parameters when making Protected Resource Metdata requests, per section 3.1 of RFC 9728.

Motivation and Context

This is important for security hardening of MCP, ensuring that clients can validate that the resource metadata they are using correlates with the resource they are accessing.

How Has This Been Tested?

We (@keycardlabs) are building an identity and access system for agents, and ensuring that SDKs are implementing the relevant OAuth bits in accordance with specifications.

Unit tests have been supplied.

Breaking Changes

This returns PRM URLs that include path components, whereas before the getOAuthProtectedResourceMetadataUrl() function did not. This may be considered a breaking change, but also brings it inline with the specifications.

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

Either a bug fix or a breaking change (or both), depending on perspective.

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

Additional context

There's a discussion about expected behavior on the OAuth mailing list.

As far as I can see, proper validation of resource indicators is very lax in the MCP specification and implementations. This is leading to a number of security vulnerabilities. I've outlined this here, and there's a related issue in the MCP specification.

I'm trying to work with both the specification authors and SDK implementers to improve the security posture of MCP. This PR is part of that effort :).

[ochafik]

Hey @jaredhanson, thanks for sending this!

I think this is now superseded by #756, but happy to reopen if not :-)