Repository navigation
Client ID Metadata Documents support #2977
Description
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.
Activity
CAOShurong commentedon Aug 23, 2026
I checked the current implementation and the authorization-server metadata to separate the responsibilities here.
AuthHandler.RegisterRoutesregisters/.well-known/oauth-protected-resourcevariants, 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.client_id.https://api.githubcopilot.com/.well-known/oauth-protected-resource/mcp, returns HTTP 200 and points clients tohttps://github.com/login/oauth.https://github.com/.well-known/oauth-authorization-server/login/oauth, currently returns issuer/authorization/token metadata but does not advertiseclient_id_metadata_document_supportedorregistration_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/oauthpass locally. Based on this boundary, #2977 cannot be implemented solely insidegithub-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-documentclient_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?