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

オープン
  • 何か問題がありますか？
#2,065 コメント 7 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
api, authentication

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
957
フォーク
174
平均マージ
13時間 16分
マージ済み PR（30日）
407

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

getsentry/toolkit のほかの issue

getsentry/toolkit の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。