OAuth Config (Optional) for Remotes

[annaji-msft]

An optional, OAuth server configuration could help here as well specifically for those MCP authorizations servers that do not support Dynamic Client Registration.

Described in the spec, Clients could hardcode the ClientId for the authorization server.

The metadata in the registry can help guide consumers a ClientId is expected for the specific MCP server as well as where to acquire it, usually link to service provider developer portals.

For reference see issue - microsoft/vscode#247759 and also briefly touched on DCR topic and clientId acquisition in the blog

The shape of this could be inspired from OAS and/or PRM

Created for tracking from PR comment - https://github.com/modelcontextprotocol/registry/pull/3/files/e9ad7352dd35f905e6216b94cf760d6bd124d8a0#r2077901936

[wagnerjt]

+1

[tadasant]

One thing not immediately obvious to me from reading this description: would this piece of work result in a reliable way to determine the answer to, "what account on what service do I need to have to be able to use this MCP server?"

For example, I'm wondering if this metadata will be enough to know that "I need an account on anthropic.com to log in to this MCP server," or if this level of metadata might do something more obscure like surface an "auth0.com" URL (assuming Anthropic delegates auth concerns to auth0) without indication that the user-facing requirement is an account on anthropic.com (and not an account on auth0.com).

I think that is a helpful piece of metadata to somehow allow incorporating for every remote server (if there is an OAuth gate present), so if not as part of this Issue, we should consider working it in elsewhere.