Register oauth clients with a preferred auth method

[kyle-leonhard]

This PR registers oauth clients with a token_endpoint_auth_method as preferred by the authorization server metadata token_endpoint_auth_methods_supported field, instead of always sending none.

If the authorization server expresses multiple preferences in token_endpoint_auth_methods_supported, the first match from: client_secret_basic, client_secret_post, none is picked. If no preference is expressed, none is picked. Unknown values are ignored.

I don't see any tests around client registration, unfortunately. I could add some with a little help from you experts!

Motivation and Context

Some MCP clients (e.g. vscode) don't currently support any token endpoint auth (microsoft/vscode#257277), but the MCP SDKs do (modelcontextprotocol/typescript-sdk#720). Without this change, one has to guess at when clients actually support token endpoint auth based on other metadata or simply always use None.

How Has This Been Tested?

I tested this locally with my MCP server and authorization server, stepping through the inspector's guided flow to check that client registration matches expectations.

• token_endpoint_auth_methods_supported is empty/absent -> client registration request is sent with client_secret_basic
• token_endpoint_auth_methods_supported=["none"] -> client registration request is sent with none
• token_endpoint_auth_methods_supported=["client_secret_basic", "client_secret_post"] -> client registration request is sent with client_secret_basic
• token_endpoint_auth_methods_supported=["client_secret_post"] -> client registration request is sent with client_secret_post
• token_endpoint_auth_methods_supported=["client_secret_basic", "client_secret_post", "none"] -> client registration request is sent with client_secret_basic

Breaking Changes

No, existing authorization server preferences continue to be respected.

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

Additional context

[kyle-leonhard]

cc @felixweinberger, @ochafik, @jaredhanson - let me know if you have thoughts and feedback!

[cliffhall]

Closing: v1 is deprecated.

Thank you for this contribution, and apologies for the long wait for a response.

v1 will receive security fixes only. We reviewed every open v1 PR for security impact before closing — see the backlog triage in #1819 — and a small number were retained for a final 1.0.5 patch release. This one is a functionality, compatibility, or cleanup change rather than a vulnerability fix, so it is being closed unmerged. This is not a judgment on the quality of the work — it's a consequence of the branch it targets being frozen.

If the underlying problem still exists in v2, we'd genuinely like to know. Please open an issue describing it against v2. Note that we accept external contributions as issues rather than pull requests — maintainers handle design and implementation through a prompt-driven workflow. See CONTRIBUTORS.md.

Thanks again for taking the time to contribute to the Inspector.