Per-user authentication for self-hosted CircleCI MCP deployments

Integrations and Accounts
1

Hello,

I’m deploying mcp-server-circleci as a centralized internal service on Kubernetes so our engineering team can use it with Claude Code. In remote mode (start=remote), the server reads CIRCLECI_TOKEN from the process environment, meaning all requests share a single token.

Our org uses SSO (SAML via OneLogin), and our developers already have SSO-authorized Personal API Tokens - so the tokens exist per user. The gap is on the server side: there’s no built-in mechanism to accept a per-request token (e.g., via Authorization: Bearer <token>), so we can’t run a shared server where each developer authenticates as themselves.

How are other teams solving this?

A few options I’ve been evaluating:

  1. Shared service account token — simplest, but all audit trail shows one identity and CircleCI’s GitHub SSO means there’s no native service account, so we’d need a dedicated bot GitHub account.

  2. oauth2-proxy in front of the MCP server — proxy enforces Google/GitHub SSO login before requests reach the MCP server. This solves access control but doesn’t solve the per-user CircleCI token problem; all calls still go through one backend token.

  3. Bearer token passthrough — modify the server to read the token from the Authorization: Bearer header per-request (using AsyncLocalStorage for async safety), falling back to the env var.

  4. Local npx per developer — each developer runs their own instance with their own token. No shared infra, but also no central deployment or version control.

Has anyone solved this in a clean way? Is there a recommended pattern for self-hosted team deployments? I’m leaning toward oauth2-proxy combined with a shared token as an interim, but I’d love to know if there’s a better path.

Regards,