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

Aberta
#2,065 7 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
api, authentication

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
TypeScript
Estrelas
957
Forks
174
Merge médio
13h 16min
PRs com merge (30d)
407

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de getsentry/toolkit

Todas as issues de getsentry/toolkit

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.