/ ディレクトリ / プレイグラウンド / Sentry
← 全サーバー ↗ GitHub
● 公式 getsentry 🔑 自分のキーが必要

Sentry

作者 getsentry · getsentry/sentry-mcp

AIエージェントにSentry調査の最初の5分間を任せてください — 問題を見つけ、スタックトレースを取得し、問題のあるリリースを特定します。

Sentryの公式MCPサーバーです。新鮮度、リリース、環境でイシューをフィルタリングし、完全なスタックトレースとブレッドクラムを取得し、リリースと相互参照できます。「何か壊れた」というSlackメッセージが、1分以内にトリアージされたインシデントに変わります。

▶ デモを見る 📦 インストール 💡 ユースケース

なぜ使うのか

主な機能

ライブデモ

実際の動作

sentry.replay ▶ 準備完了
0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json  · Windows: %APPDATA%\Claude\claude_desktop_config.json
{
  "mcpServers": {
    "sentry": {
      "command": "npx",
      "args": [
        "-y",
        "@sentry/mcp-server"
      ]
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json
{
  "mcpServers": {
    "sentry": {
      "command": "npx",
      "args": [
        "-y",
        "@sentry/mcp-server"
      ]
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit
{
  "mcpServers": {
    "sentry": {
      "command": "npx",
      "args": [
        "-y",
        "@sentry/mcp-server"
      ]
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": {
    "sentry": {
      "command": "npx",
      "args": [
        "-y",
        "@sentry/mcp-server"
      ]
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json
{
  "mcpServers": [
    {
      "name": "sentry",
      "command": "npx",
      "args": [
        "-y",
        "@sentry/mcp-server"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json
{
  "context_servers": {
    "sentry": {
      "command": {
        "path": "npx",
        "args": [
          "-y",
          "@sentry/mcp-server"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add sentry -- npx -y @sentry/mcp-server

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方： Sentry

新しい本番インシデントを5分でトリアージ

👤 オンコール対応のエンジニア ⏱ ~5 min intermediate

使うタイミング： PagerDutyがあなたを起動したばかりです。Sentryはエラーが急増していると言っています。何が起こったのか、なぜ起こったのか、リバートすべきかどうかを素早く知る必要があります。

前提条件
  • Sentry組織スラッグ + プロジェクトスラッグ — 任意のSentry URLを見てください：sentry.io/organizations/<ORG>/issues/?project=<ID>
  • event:readとproject:readを持つSentryユーザー認証トークン — sentry.io/settings/account/api/auth-tokens/
フロー
  1. 過去1時間の新規トップイシューを検索
    過去1時間のweb-prodプロジェクトにおける新規トップイシューは何ですか？イベント数でランキング。✓ コピーしました
    → タイトル、イベント数、影響を受けたユーザー、最初に確認された時刻を含む単一のイシュー
  2. 完全なスタックトレースとブレッドクラムを含む最新のイベントを取得
    そのイシューの最新イベントを取得してください。スタックトレース、リリース、クラッシュの直前の5つのブレッドクラムを表示してください。✓ コピーしました
    → 例外をスローした関数のFile:line + エラー前のユーザーアクションのシーケンス
  3. 問題を引き起こしたリリースを特定
    このイシューは最初に表示されたのと同じリリースで最初に確認されましたか、それとも以前のリリースからのものですか？リリースタグを比較してください。✓ コピーしました
    → 自信を持ったはい/いいえ — リバート決定を推進

結果： Slackに貼り付けられる3行のインシデント概要：何が壊れたか、誰が影響を受けたか、どのリリースが原因か、推奨アクション。

注意点
  • リリースタグが設定されていない場合、どのデプロイがバグを引き起こしたかを判断できません — これに依存する前に、CI内でsentry-cli releasesを設定してください — これがないと、推測するしかありません
  • スタックトレースが縮小化されたJSで読めない — ソースマップがアップロードされていることを確認してください — sentry-cli sourcemaps uploadがビルドパイプラインに含まれるべきです
組み合わせ： github · linear

Sentryエラーとそれを引き起こしたGitHubコミットを相互参照

👤 定期的な問題をデバッグしているシニアエンジニア ⏱ ~30 min advanced

使うタイミング： 各リリース後にエラーが繰り返し発生します。特定のコードパスが疑われますが、確認したいです。

前提条件
  • SentryのMCPとGitHubのMCPの両方がインストールされている — セットアップについてはGitHubガイドを参照してください
  • SentryでGit SHAでタグ付けされたリリース — CIでsentry-cli releases new $SHAを使用
フロー
  1. リリース間のイシューの履歴を一覧表示
    SentryイシューWEB-3a91について、それが現れたすべてのリリースと、リリースごとのイベント数を一覧表示してください。✓ コピーしました
    → 特定のデプロイ後にイシューが急増したことを示す表
  2. 各スパイクについてdiffを取得
    イベント数が最も多い3つのリリースについて、GitHub MCPを使用してコミットdiffを取得してください。各リリースはどのファイルを変更しましたか？✓ コピーしました
    → スパイク間の共通ファイル — 決定的証拠
  3. 根本原因の仮説を形成
    これらのdiffに基づいて、最も可能性の高い根本原因は何ですか？具体的に — 行を指してください。✓ コピーしました
    → コードをチェックして検証できる行レベルの理論

結果： SentryのイベントとGitHubのdiffの両方からの証拠を伴う、特定のコードレベルの仮説。

注意点
  • リリースに複数のコミット — どれが原因かを特定するのが難しい — git bisectスタイルを使用：半分のコミットだけでビルドをデプロイし、エラー率が低下するかを確認
組み合わせ： github

Sentryデータから週次エンジニアリング品質レポートを生成

👤 エンジニアリングマネージャー ⏱ ~20 min intermediate

使うタイミング： 金曜日の午後、来週の計画の前に。品質が上昇傾向か下降傾向かを知りたいです。

前提条件
  • Sentry内のすべてのプロジェクトへの読み取りアクセス — org:read + project:read + event:readにスコープされたトークン
フロー
  1. 週間のエラーとクラッシュフリーセッション数を取得
    当社の組織について、プロジェクトごとのクラッシュフリーセッション％を今週と先週で提供してください。低下したプロジェクトにフラグを立ててください。✓ コピーしました
    → デルタを含むプロジェクトごとの比較
  2. エラーボリュームの最大の貢献者を特定
    今週、全プロジェクト間で最も多くのイベントを引き起こしている5つのイシューは何ですか？✓ コピーしました
    → イベント数とリンクを含む具体的なイシュー一覧
  3. 来週の焦点を提案
    このデータに基づいて、チームは来週何の修正を優先すべきですか？ボリュームとユーザー影響の両方を考慮してください。✓ コピーしました
    → 3つの優先度付けされた推奨事項（理由付き）

結果： 週次エンジニアリングレビューで共有できる、具体的な優先事項を含む1ページのレポート。

注意点
  • ボリュームメトリクスが1つのノイズの多いイシューによって支配され、他のすべてをマスク — そのイシューをフィルタリングして再ランク付け — 最もノイズの多いものが最も重要とは限りません
組み合わせ： linear · notion

修正を決定する前に、既知のバグのユーザー影響を定量化

👤 プロダクトマネージャー、バグバックログをトリアージしている技術リード ⏱ ~15 min beginner

使うタイミング： 既知のバグがあり、チームが優先度について議論しています。意見ではなくデータが必要です。

フロー
  1. イシューのユーザー影響統計を取得
    SentryイシューWEB-3a91について、過去30日間に何人のユニークユーザーが遭遇し、それはアクティブユーザーの何％ですか？✓ コピーしました
    → 絶対数 + パーセンテージ
  2. 影響を受けたユーザーをセグメント化
    影響を受けたユーザーの中で、ブラウザ、OS、アカウント階層（有料対無料）による分布は？✓ コピーしました
    → エッジケースか中核フロー問題かを明らかにする詳細情報
  3. 他のオープンイシューと比較
    今月、影響を受けたユーザー数でトップ10のオープンバグをランク付けしてください。このバグはどこに位置しますか？✓ コピーしました
    → 優先順位付けのコンテキスト

結果： データ駆動型の優先度推奨：今すぐ修正、このスプリントで修正、または延期。

組み合わせ

他のMCPと組み合わせて10倍の力を

sentry + github

Sentry → 問題のあるリリースを特定 → GitHub → それを引き起こしたコミットを検索 → リバートPRを作成

イシューWEB-3a91は、リリース[email protected]の後にスパイクしました。GitHubのそのリリースのコミットを検索し、最も可能性の高い原因を特定し、リバートPRを作成してください。✓ コピーしました
sentry + linear

新しいSentryイシューで、イベント閾値を超えるLinearイシューを自動作成

過去24時間の100イベント以上の新規Sentryイシューを検索してください。それぞれについて、オンコール対応のエンジニアに割り当てられたLinearバグチケットを作成します。✓ コピーしました
sentry + notion

Notionに投稿された週次エンジニアリング品質レポート

今週のSentry統計を取得し、Engineering / Weekly ReportsデータベースにNotionページを作成してください。✓ コピーしました

ツール

このMCPが提供する機能

ツール入力呼び出すタイミングコスト
list_issues organization, project, query?, sort?, limit? ステータス、リリース、環境、経過時間でイシューストリームを検索 1 APIコール
get_issue issue_id リリース範囲を含む、特定のイシューの完全なメタデータを取得 1 APIコール
get_event issue_id, event_id? デバッグのための実際のスタックトレースとブレッドクラムを取得 1 APIコール
list_releases organization, project デプロイタイムラインを確認し、どのリリースが何を導入したかを確認 1 APIコール
list_projects organization 組織内に存在するプロジェクトを発見 1 APIコール

コストと制限

運用コスト

APIクォータ
Sentry：トークンあたり40回のリクエスト/秒（非常に寛容です）。API自体に日次キャップはありません。
呼び出しあたりのトークン
イシュー/イベント応答ごとに200～1000トークン。大きなスタックトレースは5kに達することができます。
金額
フリーティア：月額5000エラー。有料プランはAPI使用量ではなく、イベントボリュームに基づいて請求されます。
ヒント
APIは無料です。実際に支払うのはイベント取り込みです。Sentry自体のサンプリングルールを使用して、取り込みコストを予測可能に保ってください。

セキュリティ

権限、シークレット、影響範囲

最小スコープ： org:read project:read event:read
認証情報の保管： 環境変数SENTRY_AUTH_TOKENのSentryユーザー認証トークン
データ送信先： Sentryインスタンスへのすべてのコール（sentry.ioまたはセルフホスト）
絶対に付与しない： org:write project:admin member:write

トラブルシューティング

よくあるエラーと対処法

401 無効なトークン

トークンの有効期限が切れているか、要求されたスコープを持っていません。sentry.io/settings/account/api/auth-tokens/で再作成してください

確認： curl -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" https://sentry.io/api/0/organizations/
404 プロジェクトが見つかりません

プロジェクトスラッグは大文字と小文字を区別し、URLと正確に一致する必要があります。sentry.io/settings/projects/を確認してください

スタックトレースが空です

ソースマップがアップロードされていません。ビルドパイプラインの一部としてsentry-cli sourcemaps uploadを実行してください。

代替案

Sentry 他との比較

代替案代わりに使う場面トレードオフ
Datadog APM MCP既にDatadogを使用しており、統一されたAPM + エラーが必要な場合より高額で、エラーに特化していない
Rollbar / Bugsnag MCP既にそれらの費用を支払っている場合より小さなコミュニティが構築したMCPエコシステム

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る