Bug: Google HTTP MCP servers fail with serviceusage.services.use while local Google MCP adapter works

[adeze]

Summary

When using Google Cloud MCP servers from Copilot CLI, a local Google MCP adapter works, but Google-managed remote HTTP MCP servers fail with a permissions error even though IAM and impersonation are configured correctly.

In the same environment:

• a local observability MCP server works
• Google-managed logging and developerknowledge HTTP MCP servers fail
• direct impersonated HTTP calls to the same Google-managed MCP endpoints succeed
• Gemini CLI can access the same project successfully

This makes it look like Copilot CLI's Google HTTP MCP auth path is using the wrong effective Google identity, or not honoring the intended ADC / impersonated identity.

Affected version

GitHub Copilot CLI 1.0.7

Environment

• OS: macOS (Darwin)
• Project: yourproject-id
• Google Cloud remote MCP config uses authProviderType: "google_credentials"
• ADC quota project is set to yourproject-id

Problem detail

What works

1. Local MCP server: observability (from gcloud-mcp)

   • Copilot talks to a local MCP process
   • The local process uses local Google auth itself
   • This works successfully against the project

2. Direct impersonated HTTP calls to Google-managed MCP endpoints

   • https://logging.googleapis.com/mcp
   • https://developerknowledge.googleapis.com/mcp
   • These succeed when called directly with an impersonated access token

3. Gemini CLI in the same environment can use the same Google Cloud project successfully

What fails

Google-managed remote HTTP MCP servers configured in ~/.copilot/mcp-config.json with authProviderType: "google_credentials":

• https://logging.googleapis.com/mcp
• https://developerknowledge.googleapis.com/mcp

These fail in Copilot CLI with a permission error consistent with the request reaching Google under the wrong effective identity.

Error

The failure is:

serviceusage.services.use

More specifically, the error indicates the caller does not have the required serviceusage.services.use permission, even though the intended user/service-account path does have the required roles.

Why this looks like a Copilot CLI auth-path bug

The key distinction is:

• observability works because it is a local MCP server. Copilot talks to a local process, and that process uses local Google auth itself.
• logging / developerknowledge fail because they are Google-managed remote HTTP MCP servers. Copilot must attach Google credentials directly when calling logging.googleapis.com/mcp / developerknowledge.googleapis.com/mcp.

Since all of the following are true:

• local observability works
• Gemini CLI works
• direct impersonated HTTP calls work
• IAM roles are present
• quota project is configured

…the remaining failure seems specific to Copilot CLI’s handling of Google credentials for remote HTTP MCP servers.

IAM / auth verification already performed

The following were verified in the affected project:

• user has roles/mcp.toolUser
• user has roles/serviceusage.serviceUsageConsumer
• ADC quota project is set correctly
• a dedicated service account was created and granted the same relevant project roles
• user was granted roles/iam.serviceAccountTokenCreator on that service account
• direct impersonated access-token calls to the failing MCP endpoints succeed

This strongly suggests project-side IAM is not the root cause.

Reproduction sketch

1. Configure a local Google MCP adapter such as observability and confirm it works.
2. Configure a Google-managed remote HTTP MCP server like this:

{
  "mcpServers": {
    "logging": {
      "type": "http",
      "url": "https://logging.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": ["https://www.googleapis.com/auth/cloud-platform"]
      },
      "headers": {
        "x-goog-user-project": "yourproject-id"
      }
    }
  }
}

3. Restart Copilot CLI.
4. Call a logging-* tool.
5. Observe serviceusage.services.use permission failure.
6. Independently call the same endpoint with a direct impersonated access token.
7. Observe that the direct call succeeds.

Expected behavior

If Copilot CLI is configured to use Google credentials for a Google-managed HTTP MCP server, it should use the same effective Google identity that succeeds via local Google tooling / ADC / impersonation, or at least fail in a way that makes the effective principal obvious.

Actual behavior

Local Google MCP adapter works, but Google-managed remote HTTP MCP calls fail with serviceusage.services.use, despite verified IAM and successful direct impersonated calls.

Request

Could you please confirm whether Copilot CLI’s google_credentials auth path for HTTP MCP servers:

• honors impersonated ADC / application-default credentials as expected
• may be selecting a different credential source than local Google tooling
• can surface which Google principal it is actually using for the remote HTTP MCP request

That would help determine whether this is a CLI auth-source bug, an ADC/impersonation support gap, or an expected limitation.