/ 目錄 / 演練場 / Sentry
← 全部伺服器 ↗ GitHub
● 官方 getsentry 🔑 需要你的金鑰

Sentry

作者 getsentry · getsentry/sentry-mcp

讓你的 AI agent 在每次 Sentry 調查的前 5 分鐘內完成工作——找出問題、拉取堆棧跟蹤、識別問題發佈版本。

Sentry 官方 MCP 伺服器。按時間戳/發佈版本/環境篩選議題、取得完整堆棧跟蹤和麵包屑、交叉參考發佈版本。把「有東西掛了」的 Slack 通知變成經過分類的事件，只需一分鐘。

▶ 觀看演示 📦 安裝 💡 使用場景

為什麼要用

核心特性

即時演示

實際使用效果

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 組織 slug + 專案 slug — 查看任何 Sentry URL：sentry.io/organizations/<ORG>/issues/?project=<ID>
  • 具有 event:read 和 project:read 權限的 Sentry 使用者身份驗證令牌 — sentry.io/settings/account/api/auth-tokens/
步驟
  1. 尋找過去一小時內最新的問題
    過去一小時內，我們 web-prod 專案中排名最高的新議題是什麼（按事件數量排序）？✓ 已複製
    → 單一議題，包括標題、事件數量、受影響的使用者、首次發現的時間戳
  2. 取得最新事件，包含完整堆棧跟蹤和麵包屑
    取得該議題的最新事件。向我展示堆棧跡蹤、發佈版本和崩潰前的最後 5 個麵包屑。✓ 已複製
    → 拋出異常函式的檔案:行號 + 錯誤前的使用者動作序列
  3. 識別導致問題的發佈版本
    這個議題是在出現的同一個發佈版本中首次出現，還是從之前的版本延續下來的？比較發佈版本標籤。✓ 已複製
    → 是/否，並說明信心度——這會驅動回滾決定

結果： 一份 3 行的事件摘要，你可以貼到 Slack：什麼壞了、誰受影響了、哪個發佈版本引起的、建議的動作。

注意事項
  • 如果你的發佈版本標籤沒有配置好，你無法知道哪個部署引入了這個 bug — 在依賴此功能之前，在 CI 中設定 sentry-cli releases——否則你只是在猜測
  • 堆棧跡蹤是縮小化的 JS，無法讀取 — 驗證 sourcemap 是否已上傳——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. 對於每個激增，取得差異
    對於事件數量最多的 3 個發佈版本，使用 GitHub MCP 取得提交差異。每個發佈版本改變了哪些檔案？✓ 已複製
    → 激增中的常見檔案——明確的證據
  3. 形成根本原因假設
    根據這些差異，最可能的根本原因是什麼？要具體——指出具體的行號。✓ 已複製
    → 你可以通過檢查代碼來驗證的行級別理論

結果： 一個具體的代碼級別假設，有來自 Sentry 事件和 GitHub 差異的證據。

注意事項
  • 一個發佈版本中有多個提交——很難隔離哪個是責任方 — 使用 git bisect 風格：部署一個只包含一半提交的構建，並檢查錯誤率是否下降
搭配使用： github

從 Sentry 資料產生每週工程品質報告

👤 工程經理 ⏱ ~20 min intermediate

何時使用： 週五下午，下週計劃前。你想知道品質是否在上升或下降。

前置條件
  • 對 Sentry 中所有專案的讀取權限 — 令牌的範圍為 org:read + project:read + event:read
步驟
  1. 拉取本週的錯誤和無崩潰工作階段數量
    對於我們的組織，給我本週與上週每個專案的無崩潰工作階段百分比。標記任何下降的專案。✓ 已複製
    → 每個專案的比較及差異
  2. 識別導致錯誤量的主要貢獻者
    本週在所有專案中，哪 5 個議題造成的事件最多？✓ 已複製
    → 具體的議題列表，包括事件數量和連結
  3. 建議下週的關注重點
    根據這些資料，團隊下週應該優先修復什麼？同時考慮數量和使用者影響。✓ 已複製
    → 3 個優先級別的建議及理由

結果： 一份 1 頁的報告，你可以在每週工程審查中分享，包含具體的優先事項。

注意事項
  • 數量指標由一個噪音很大的議題主導，掩蓋了其他一切 — 過濾掉該議題並重新排名——有時最噪音的不是最重要的
搭配使用： linear · notion

在決定修復前量化已知 bug 對使用者的影響

👤 產品經理、bug 積壓分類的技術主管 ⏱ ~15 min beginner

何時使用： 有一個已知的 bug，團隊正在爭論優先級。你需要資料，而不是意見。

步驟
  1. 拉取議題的使用者影響統計
    對於 Sentry 議題 WEB-3a91，過去 30 天內有多少個獨特使用者遇到過它，佔總活躍使用者的百分比是多少？✓ 已複製
    → 絕對數量 + 百分比
  2. 分類受影響的使用者
    在受影響的使用者中，按瀏覽器、作業系統和帳戶層級（付費 vs 免費）的分佈是什麼？✓ 已複製
    → 分解，揭示它是邊界情況還是核心流程問題
  3. 與其他開放的議題比較
    按本月受影響的使用者排名我們排名前 10 的開放 bug。這個排名在哪裡？✓ 已複製
    → 優先級別的背景

結果： 一個資料驅動的優先級別建議：現在修復、本衝刺修復或延後。

組合

與其他 MCP 搭配，撬動十倍槓桿

sentry + github

Sentry → 識別問題發佈版本 → GitHub → 找出引入它的提交 → 起草回滾 PR

議題 WEB-3a91 在發佈版本 [email protected] 後激增。在 GitHub 上找出該發佈版本中的提交，識別最可能的責任方，並起草一個回滾 PR。✓ 已複製
sentry + linear

從超過事件閾值的新 Sentry 議題自動建立 Linear 議題

找出過去 24 小時內所有超過 100 個事件的新 Sentry 議題。對於每一個，建立一個分配給值班工程師的 Linear bug 票證。✓ 已複製
sentry + notion

週度工程品質報告發布到 Notion

拉取本週的 Sentry 統計資料，並在工程 / 週報資料庫中建立一個 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 req/sec（非常慷慨）。API 本身沒有每日上限。
每次呼叫 Token 數
每個議題/事件回應 200–1000 個令牌；大型堆棧跡蹤可能達到 5k
費用
免費層級：每月 5k 錯誤。付費計畫按事件數量計費，而非 API 使用量。
提示
API 是免費的；你真正付費的是事件注入。使用 Sentry 本身的採樣規則來保持注入成本可預測。

安全

權限、密鑰、影響範圍

最小權限： org:read project:read event:read
憑證儲存： Sentry 使用者身份驗證令牌在環境變數 SENTRY_AUTH_TOKEN 中
資料出站： 所有呼叫到你的 Sentry 實例（sentry.io 或自託管）
切勿授予： org:write project:admin member:write

故障排查

常見錯誤與修復

401 Invalid token

令牌已過期或沒有請求的範圍。重新建立於 sentry.io/settings/account/api/auth-tokens/

驗證： curl -H "Authorization: Bearer $SENTRY_AUTH_TOKEN" https://sentry.io/api/0/organizations/
404 Project not found

專案 slug 區分大小寫，必須與 URL 完全符合。檢查 sentry.io/settings/projects/

Empty stacktrace

未上傳 Sourcemap。在構建管道中執行 sentry-cli sourcemaps upload。

替代方案

Sentry 對比其他方案

替代方案何時用它替代權衡
Datadog APM MCP你已經在使用 Datadog，想要統一的 APM + 錯誤更昂貴，對錯誤的關注不夠具體
Rollbar / Bugsnag MCP你已經為他們付費較小的社區構建 MCP 生態系統

更多

資源

📖 閱讀 GitHub 上的官方 README

🐙 查看未解決的 issue

🔍 瀏覽全部 400+ MCP 伺服器和 Skills