Support Bearer token authentication for API gateway use cases

[jds2501-cs]

Problem

Sentry MCP's natural language search tools fail when routing through Anthropic-compatible API gateways that require Bearer token authentication:

invalid access token key

This affects 4 tools that use embedded AI agents:

• search_issues - Natural language → Sentry issue search
• search_events - Natural language → event search across datasets
• search_issue_events - Natural language → filtered events within an issue
• use_sentry - Full agentic interface

Root Cause

Sentry MCP only recognizes ANTHROPIC_API_KEY, which causes the Vercel AI SDK to send x-api-key headers. Some API gateways require Authorization: Bearer headers for OAuth 2.0 compliance.

The underlying Vercel AI SDK (@ai-sdk/anthropic) already supports both methods:

• apiKey → x-api-key header (direct Anthropic API)
• authToken → Authorization: Bearer header (gateway routing)

Use Case

Enterprise users want to route Anthropic requests through internal API gateways for:

• Centralized billing/quota management
• Security/compliance monitoring
• Abstraction of underlying AI providers
• Integration with SSO/identity systems

Example scenario: A company's internal API gateway provides Bearer tokens that handle backend provider authentication internally.

Proposed Solution

Recognize ANTHROPIC_AUTH_TOKEN environment variable alongside ANTHROPIC_API_KEY:

// packages/mcp-core/src/internal/agents/anthropic-provider.ts
export function getAnthropicModel(model?: string): LanguageModel {
  const authToken = process.env.ANTHROPIC_AUTH_TOKEN;
  const apiKey = process.env.ANTHROPIC_API_KEY;

  const factory = createAnthropic({
    // Pass authToken (Bearer) OR apiKey (x-api-key), with authToken taking precedence
    ...(authToken ? { authToken } : apiKey ? { apiKey } : {}),
    ...(configuredBaseUrl && { baseURL: configuredBaseUrl }),
    headers: { "User-Agent": USER_AGENT },
  });

  return factory(model ?? defaultModel);
}

Files Requiring Changes

1. packages/mcp-core/src/internal/agents/anthropic-provider.ts - Core auth logic
2. packages/mcp-core/src/internal/agents/provider-factory.ts - Credential validation (4 functions)
3. packages/mcp-server/src/index.ts - CLI warning helpers (2 functions)
4. packages/mcp-server/src/cli/usage.ts - Help text
5. packages/mcp-core/src/internal/agents/anthropic-provider.test.ts - New test file
6. packages/mcp-core/src/internal/agents/provider-factory.test.ts - Extend existing tests
7. docs/embedded-agents.md - Documentation

Backward Compatibility

• Existing ANTHROPIC_API_KEY users: No changes needed
• New gateway users: Set ANTHROPIC_AUTH_TOKEN instead
• Both set: ANTHROPIC_AUTH_TOKEN takes precedence (explicit gateway use)

Configuration Example

{
  "mcpServers": {
    "sentry": {
      "command": "npx",
      "args": [
        "@sentry/mcp-server",
        "--anthropic-base-url=https://genaihub.example.com"
      ],
      "env": {
        "SENTRY_ACCESS_TOKEN": "sntrys_...",
        "EMBEDDED_AGENT_PROVIDER": "anthropic",
        "ANTHROPIC_AUTH_TOKEN": "your-bearer-token"
      }
    }
  }
}

[dcramer]

We can probably do this however Id want to make sure that it won’t interfere with any local anthropic products. It might be that the provider key setting is enough and we don’t need to worry about it, but one of the fair previous complaints was having true env automatically pick up config like this will cause accidents and/or confusion.

[jds2501-cs]

Could we use an explicit opt-in flag to manage that risk? Something like:

{
"args": [
"@sentry/mcp-server",
"--anthropic-base-url=https://gateway.example.com",
"--anthropic-use-bearer-auth"
],
"env": {
"ANTHROPIC_AUTH_TOKEN": "..."
}
}