Support API key authentication for per-project MCP configuration

Problem

When using the PostHog MCP server with multiple PostHog organizations (e.g., separate orgs for different projects), there's no way to configure per-project authentication. The MCP server currently only supports OAuth, and OAuth credentials are stored globally keyed by server URL. This means all projects sharing the same PostHog Cloud instance (e.g., mcp.posthog.com) share a single OAuth session.

Switching between orgs requires manually clearing OAuth credentials and re-authenticating through the browser flow each time you change projects, which is disruptive.

Proposed solution

Support an environment variable for API key authentication, e.g. POSTHOG_API_KEY, as an alternative to OAuth. This would allow users to:

1. Set different API keys per project (via .env, project-level MCP config, or IDE settings)
2. Avoid repeated OAuth re-authentication when switching between projects tied to different orgs
3. Use the MCP server in non-interactive / CI environments

Example configuration

{
  "mcpServers": {
    "posthog": {
      "type": "http",
      "url": "${POSTHOG_MCP_URL:-https://mcp.posthog.com/mcp}",
      "headers": {
        "Authorization": "Bearer ${POSTHOG_API_KEY}"
      }
    }
  }
}

Or handled server-side, where the MCP server accepts an API key and skips OAuth when one is provided.

Current workaround

The only workaround is to clear the OAuth token in ~/.config/claude/.credentials.json and re-authenticate each time you switch projects — not practical for frequent context switching.

Environment

• Claude Code with PostHog plugin v1.0.0
• Multiple PostHog organizations on the same cloud instance (US)

Start by locating the MCP server authentication entry point and the handling for OAuth credentials stored in ~/.config/claude/.credentials.json. Confirm whether this repository controls the hosted server or only the plugin configuration, then trace how an Authorization bearer key could be accepted alongside OAuth. Done means distinct project-level API keys work without clearing OAuth credentials, including non-interactive use, with tests covering both authentication paths.