Remote MCP: let Bearer-only clients opt into direct token auth (a `Sentry-Bearer` equivalent)

Aperta
#2,065 7 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript

Direzione di ricerca

Start by tracing the remote MCP router and the existing Sentry-Bearer authentication path; the issue does not name files or tests. Check how /mcp selects OAuth and how token-keyed rate limiting and skills narrowing are applied. Done means an explicit URL opt-in accepts Bearer tokens through the existing direct-token behavior and returns a plain 401 for missing or malformed auth, while default /mcp OAuth behavior stays unchanged.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

Authorization: Sentry-Bearer <token> on mcp.sentry.dev works well for automation, but some MCP clients can only send Authorization: Bearer <token> and have no way to set a custom scheme or header.

Concretely: Claude Managed Agents. An agent's MCP server entry is just {type, name, url}, and its credential store (vaults) has two MCP credential types, mcp_oauth and static_bearer. Both are sent as Authorization: Bearer …. There is no headers field, so such a client can't reach the direct-token mode at all, even with a valid, narrowly scoped token.

Our case is an internal integration token (Issue & Event read/write, Project read) used by an agent that triages new production errors and opens draft PRs. A person reviews every PR, but no person is present when the agent runs, so OAuth's interactive grant doesn't fit. The other option, OAuth under a person's account, gives broader access than the integration token.

Proposal

Keep Bearer on /mcp meaning MCP OAuth, as it does today. Add an explicit, URL-level opt-in where Bearer carries a raw Sentry token, handled exactly like Sentry-Bearer. For example:

https://mcp.sentry.dev/mcp-token/:org[/:project]?skills=inspect
Authorization: Bearer <sentry api token>

(or a query flag on /mcp such as ?auth=sentry-token, whichever fits the router better).

  • The same code path as Sentry-Bearer, with no change to what that mode does: no storage, no refresh, the Sentry API is the permission boundary, skills narrowing still applies, and the same token-keyed rate limiting.
  • The opt-in sits in the URL, which every MCP client lets you configure. The token stays in the header. Nothing changes for OAuth clients, and a client can never fall into this mode by accident.
  • Missing or malformed auth on this route returns a plain 401, with no OAuth discovery challenge.

Current workaround

We run a small Cloudflare Worker that rewrites Bearer to Sentry-Bearer and forwards to mcp.sentry.dev/mcp/<org>?skills=inspect. It works, but every team that hits this has to deploy and trust its own proxy in the token path, which an upstream opt-in would avoid.

Related: #833 (closed by the Sentry-Bearer mode). This request only concerns clients that can't set that header.

Lingua principale
TypeScript
Stelle
957
Fork
174
Merge medio
13h 16m
PR unite (30g)
407

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di getsentry/toolkit

Tutte le issue di getsentry/toolkit

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.