Description
Adding the Datadog remote MCP server via the /mcp wizard fails during OAuth. The authorization step in the browser completes successfully (user signs in and grants permission), but the CLI then fails during token exchange with:
Authentication failed: MCPOAuthError: Token exchange failed: Server returned error response: invalid_grant: The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client.
Config used
Added via the /mcp wizard with:
- Type:
HTTP
- URL:
https://mcp.datadoghq.com/v1/mcp
- All other fields left as default
Environment
- GitHub Copilot CLI version: 1.0.91
- OS: macOS
- Usage: plain terminal/bash session (no IDE involved)
Notes / likely related
This looks like the same family of bug reported in several other MCP OAuth issues in this repo involving Dynamic Client Registration (DCR) and the client_id/token-exchange handoff (e.g. #4906, #4923, #4795, #4769), where metadata discovery and DCR succeed but the subsequent authorize/token round-trip ends up using a mismatched client/redirect URI/code verifier.
A closely matching symptom was also reported against the IntelliJ Copilot plugin for the exact same Datadog MCP endpoint (https://mcp.datadoghq.com/v1/mcp), where Datadog's authorize endpoint rejected the DCR-issued client_id outright (invalid_request - Invalid client_id parameter value), and a later run of the same flow surfaced as invalid_grant - Invalid or expired refresh token or code verifier: microsoft/copilot-intellij-feedback#1889. Since both products share underlying Copilot MCP OAuth/DCR client logic, this may be the same root cause surfacing in the CLI as a clean invalid_grant at the token exchange step.
Datadog's discovered OAuth metadata (from the IntelliJ report, same server):
authorization_endpoint: https://app.datadoghq.com/oauth2/v1/authorize
token_endpoint: https://app.datadoghq.com/oauth2/v1/token
oauth_version: 2.1
grant_types_supported: [authorization_code, refresh_token]
code_challenge_methods_supported: [S256]
pkce_required: true
registration_endpoint: https://app.datadoghq.com/api/v2/oauth2/register
token_endpoint_auth_methods_supported: [client_secret_post, none]
Expected behavior
The Datadog MCP server should authenticate successfully via OAuth/DCR from the CLI, completing the full authorize → token exchange flow without invalid_grant.
Steps to reproduce
- Run
/mcp in the CLI, choose "Add server".
- Type: HTTP, URL:
https://mcp.datadoghq.com/v1/mcp, leave everything else default.
- Complete the browser sign-in/consent flow when prompted.
- Observe the CLI reports
Authentication failed: MCPOAuthError: Token exchange failed... invalid_grant.
Description
Adding the Datadog remote MCP server via the
/mcpwizard fails during OAuth. The authorization step in the browser completes successfully (user signs in and grants permission), but the CLI then fails during token exchange with:Config used
Added via the
/mcpwizard with:HTTPhttps://mcp.datadoghq.com/v1/mcpEnvironment
Notes / likely related
This looks like the same family of bug reported in several other MCP OAuth issues in this repo involving Dynamic Client Registration (DCR) and the
client_id/token-exchange handoff (e.g. #4906, #4923, #4795, #4769), where metadata discovery and DCR succeed but the subsequent authorize/token round-trip ends up using a mismatched client/redirect URI/code verifier.A closely matching symptom was also reported against the IntelliJ Copilot plugin for the exact same Datadog MCP endpoint (
https://mcp.datadoghq.com/v1/mcp), where Datadog's authorize endpoint rejected the DCR-issuedclient_idoutright (invalid_request - Invalid client_id parameter value), and a later run of the same flow surfaced asinvalid_grant - Invalid or expired refresh token or code verifier: microsoft/copilot-intellij-feedback#1889. Since both products share underlying Copilot MCP OAuth/DCR client logic, this may be the same root cause surfacing in the CLI as a cleaninvalid_grantat the token exchange step.Datadog's discovered OAuth metadata (from the IntelliJ report, same server):
Expected behavior
The Datadog MCP server should authenticate successfully via OAuth/DCR from the CLI, completing the full authorize → token exchange flow without
invalid_grant.Steps to reproduce
/mcpin the CLI, choose "Add server".https://mcp.datadoghq.com/v1/mcp, leave everything else default.Authentication failed: MCPOAuthError: Token exchange failed... invalid_grant.