Can LiteLLM MCP Gateway connect to GitHub Copilot MCP using OAuth 2.1 + DCR instead of PAT?

[Sanady]

I’m trying to add the official GitHub Copilot MCP server to LiteLLM MCP Gateway through the LiteLLM UI.

The remote MCP server URL is:

https://api.githubcopilot.com/mcp/

I want to avoid using a GitHub PAT and instead use the OAuth flow, ideally OAuth 2.1 with Dynamic Client Registration (DCR).

GitHub’s documentation and changelog suggest enhanced MCP OAuth support and DCR support, but I’m not sure how this should be configured specifically in LiteLLM.

In LiteLLM UI, I tried configuring the MCP server with:

Authentication: OAuth
Authorization URL Override: https://github.com/login/oauth/authorize
Token URL Override: https://github.com/login/oauth/access_token

I also checked the metadata from:

https://api.githubcopilot.com/.well-known/oauth-protected-resource/mcp

However, during the authorization flow, LiteLLM returns errors such as:

{"detail": "MCP server authorization url is not set"}

or:

{"detail": "invalid_request"}

Questions

1. Does LiteLLM currently support connecting to GitHub Copilot MCP using OAuth 2.1 with Dynamic Client Registration?
2. If yes, what exact LiteLLM UI fields should be configured for:
   • MCP server URL
   • authorization URL
   • token URL
   • registration URL
   • client ID / client secret
   • callback / redirect URI
3. If DCR is not supported in this setup, is the only OAuth option to pre-register a GitHub OAuth App or GitHub App and manually provide the client ID and client secret?
4. Is PAT currently the only fully working authentication method for GitHub Copilot MCP behind LiteLLM?

I’m looking for the recommended production setup for GitHub Copilot MCP through LiteLLM without using PAT-based authentication.

[itzabhinavarya]

I was trying to achieve the same setup recently.

From what I can tell, LiteLLM’s MCP OAuth flow does not yet fully support GitHub Copilot MCP’s OAuth 2.1 + DCR flow out of the box. It seems to expect pre-configured authorization details instead of dynamically registering the client.

The invalid_request and missing authorization URL errors also suggest partial OAuth support rather than full DCR support currently.

Would be great if LiteLLM could officially document:

• GitHub Copilot MCP integration
• supported OAuth flows
• DCR compatibility
• required redirect URI format

Right now PAT seems to be the most reliable working approach.

[SamMorrowDrums]

We don't support DCR and we are not going to be able to do so. I hope we can eventually support CIMD, but until then there are two options:

Pre-register a GitHub App (or GitHub Oauth App) and provide the client credentials hard coded, I know some MCP clients support this and this is the expected path and official fallback when DCR is not available in the MCP spec.

If the gateway or client doesn't support this, the alternative is PAT or course, although of course that is less than ideal.

I don't know in the specific case of the gateway you referenced, but pre-registering app is a solid approach and if they don't support you could ask. Not all auth servers support DCR (it's not just GitHub that doesn't), unfortunately it's not a good design and we cannot risk our existing and pretty load bearing app infrastructure on DCR.

Let me know if you need any advice. I know for example OpenCode has documentation for pre-registration of app, and then that is standard Oauth login after that and works well.

[musaabhasan]

Given the maintainer note that DCR is not supported, I would avoid forcing this through a PAT and instead choose between two explicit models:

1. Registered OAuth/GitHub App client: pre-register the client, store client metadata in the gateway, and let users authorize through the normal OAuth flow.
2. Server-side service integration: if the gateway is operated by an organization, use a managed app installation or service identity with scoped permissions.

The important part is to keep the trust boundary clear. The LiteLLM gateway should not silently become a credential broker for broad user tokens unless it also has token storage, refresh, revocation, audit logging, and per-tool authorization controls.

For a practical configuration checklist, I would want to verify:

• exact redirect URI expected by LiteLLM
• whether refresh tokens are stored encrypted
• whether token scopes are narrower than a PAT equivalent
• whether tokens are per-user or shared deployment credentials
• whether MCP tool calls are logged with user identity and tool name

Until CIMD or a fully compatible flow exists, a pre-registered app is less elegant than DCR but much safer than treating PATs as the default answer.