Client ID Metadata Documents support

[bart-westenenk-bex]

Describe the feature or problem you’d like to solve

Client ID Metadata Documents are the new standard way to authorize through OAuth, without preregistering a client. My organization disallows using PAT's for our private repositories as they give too much access and they can't control who can make PAT's. Fine grained access tokens are not supported by the MCP, so OAuth is the next step.

Proposed solution

The MCP Server can be used by way more clients than Visual Studio Code and Copilot CLI alone, expanding the usefulness of the MCP server over using the gh CLI.

Example prompts or workflows (for tools/toolsets only)

N/A

Additional context

Add any other context like screenshots or mockups are helpful, if applicable.

[CAOShurong]

I checked the current implementation and the authorization-server metadata to separate the responsibilities here.

• The MCP server currently implements RFC 9728 Protected Resource Metadata only: AuthHandler.RegisterRoutes registers /.well-known/oauth-protected-resource variants, and the response contains the resource URL, authorization server, scopes, and bearer method (oauth.go). It does not implement an authorization server, client registration, or client-metadata resolution endpoint.
• The MCP Client ID Metadata Documents specification defines this as a client/authorization-server registration mechanism: the client hosts the HTTPS metadata document and the authorization server decides whether to accept a URL client_id.
• The current hosted resource metadata endpoint, https://api.githubcopilot.com/.well-known/oauth-protected-resource/mcp, returns HTTP 200 and points clients to https://github.com/login/oauth.
• The corresponding RFC 8414 metadata endpoint, https://github.com/.well-known/oauth-authorization-server/login/oauth, currently returns issuer/authorization/token metadata but does not advertise client_id_metadata_document_supported or registration_endpoint. That means MCP clients cannot assume either registration mechanism is available from the advertised authorization server.

The focused OAuth package tests and go vet ./pkg/http/oauth pass locally. Based on this boundary, #2977 cannot be implemented solely inside github-mcp-server: the enabling decision is in GitHub's OAuth authorization server and/or the MCP host. Once the authorization server advertises CIMD support, this repository could document the interoperability requirement and add an integration check, but adding a server-side client-metadata route would not make GitHub OAuth accept a metadata-document client_id.

Could this issue be tracked with the GitHub OAuth platform/host owners, or should the MCP server documentation explicitly record that CIMD is currently unavailable through the advertised authorization server?