MCP Spotlight: Sentry MCP Server — The Error Tracking Bridge With Seer AI Autofix, Issue Sync to GitHub/Linear/Jira, and the Production-Observability Default for Agents
Server: Sentry MCP Server by Sentry License: MIT (open source) · Status: GA, official Sentry-maintained Tools: ~22 (issues, events, projects, releases, performance, replays, AI analysis) Auth: Sentry auth token, OAuth 2.0 Coverage: Errors · Performance · Releases · Replays · Source maps · Issue management · Seer AI analysis Integrations: GitHub, GitLab, Bitbucket, Linear, Jira, Azure DevOps (issue sync, code mapping, PR linking) Docs: docs.sentry.io/product/ai-integration/mcp-server/ MCP Tracker: glama.ai/mcp/servers?query=sentry
Every agent workflow that touches production code eventually needs to debug a real error in a real environment. The "log into Sentry's web UI" approach is manual and context-switch-heavy. The "give the agent raw access to Sentry's API" approach dumps 200+ endpoints into the model. The naive "wrap Sentry with a 100-tool generic API MCP" approach bloats the context window without surfacing what agents actually need.
The official Sentry MCP Server is the bridge that resolves this. ~22 tools covering the production-observability workflow: find issues, fetch events, read stack traces, check release health, pull performance traces, inspect user replays, analyze with Seer AI (Sentry's own root-cause-analysis agent), and link to source code via GitHub/Linear/Jira. MIT-licensed. Maintained by Sentry itself.
This is the production-debugging default of 2026.
The Architecture: Production-Observability Workflows
The Sentry MCP Server's tool surface is organized around how production debugging actually flows:
| Category | Tools | Purpose |
|---|---|---|
| Issues | list_issues, get_issue, update_issue, resolve_issue, assign_issue | Triage and lifecycle |
| Events | get_event, get_latest_event, list_events, get_stacktrace | Read errors and traces |
| Projects | list_projects, get_project, list_project_members | Workspace navigation |
| Releases | list_releases, get_release, get_release_health, create_release | Deployment tracking |
| Performance | list_transactions, get_transaction, get_trace_details, get_performance_summary | Latency + throughput |
| Replays | list_replays, get_replay, get_replay_console_logs | User-session playback |
| Source Code | get_source_map_debug_id, resolve_source_file | Decoded stack frames |
| AI Analysis | analyze_issue_with_seer, get_seer_fix_suggestion, apply_seer_fix | Sentry's own AI debugging |
| Issue Sync | link_issue_to_linear, link_issue_to_jira, link_issue_to_github, unlink_issue | Cross-tool linking |
The tools are focused — no 200-tool API dump. The agent gets the high-leverage primitives and composes them into production-debugging workflows.
The Killer Feature: Seer AI Autofix
The single biggest differentiator: Seer AI, Sentry's own root-cause-analysis agent, is accessible directly from MCP.
User: "Production is on fire. /api/checkout is throwing 500s.
Find the cause and propose a fix."
Agent:
1. list_issues(project="api", query="transaction:/api/checkout level:error")
→ Returns the top issues by frequency
2. get_issue(issue_id=...)
→ Returns full issue context: stack trace, tags, user context
3. get_latest_event(issue_id=...)
→ Returns the most recent occurrence's breadcrumbs, request data
4. analyze_issue_with_seer(issue_id=...)
→ Seer reads the code, the stack trace, the breadcrumbs, and produces
a root-cause analysis with file paths and line numbers
5. get_seer_fix_suggestion(issue_id=...)
→ Seer returns a suggested code patch
6. apply_seer_fix(...)
→ Opens a PR (via GitHub MCP) with the suggested patch
7. Returns summary to user with link to the PR
This is production-debugging with AI on both sides — the agent on one side, Seer on the other, both analyzing the same error context. The result: root-cause analysis in minutes instead of hours.
Seer's analysis is grounded in:
- The actual stack trace and decoded source frames
- The breadcrumbs leading up to the error
- The commit history of the affected files
- The release the error first appeared in
- The frequency and user-impact profile
For teams running production services, this is the closest thing to having a senior engineer on call 24/7 — and it's accessible directly from any MCP-enabled agent.
Release Health & Regression Detection
The release tools are the unsung hero of the production-debugging workflow:
| Tool | What It Does |
|---|---|
list_releases | List all releases with commit metadata, deploy time, author |
get_release | Get release details: commits, files changed, associated issues |
get_release_health | Crash-free session rate, crash-free user rate, adoption |
get_release_files_changed | Diff between this release and the previous |
The regression-detection pattern is straightforward:
User: "We deployed v1.2.3 yesterday. Did it break anything?"
Agent:
1. list_releases(project="api", limit=5)
→ Confirms v1.2.3 is the latest
2. get_release_health(release="v1.2.3")
→ Returns crash-free rate (was 99.8%, now 99.2%)
3. list_issues(project="api", firstSeen=v1.2.3)
→ Returns issues that first appeared in this release
4. For each new issue, get_issue + analyze_issue_with_seer
5. Surfaces regression report to user with severity + suggested fixes
The agent combines release metadata + error frequency + root-cause analysis into a deployment-impact report. What takes a senior engineer an hour takes the agent 30 seconds.
Performance + Trace Analysis
The performance tools expose Sentry's distributed tracing:
| Tool | What It Does |
|---|---|
list_transactions | List all transaction endpoints with p50/p95/p99 latency |
get_transaction | Detailed transaction breakdown: spans, DB queries, external calls |
get_trace_details | Full distributed trace across services |
get_performance_summary | Aggregated performance metrics for a project |
The agent can answer performance questions like:
"Why is /api/checkout taking 2.3s when it used to take 400ms?"
Agent:
1. get_transaction(transaction="/api/checkout")
→ Returns span breakdown
2. Identifies a slow DB query: 1.8s on `SELECT * FROM orders WHERE...`
3. get_performance_summary()
→ Confirms DB query is the bottleneck
4. Surfaces the slow query to the user with EXPLAIN recommendation
The agent does distributed-trace analysis in minutes. The pattern is the same as debugging errors: pull the trace, identify the slow span, propose a fix.
Replay: Watch the User
For frontend bugs, the Replay tools are invaluable:
User: "Customer says checkout doesn't work on mobile."
Agent:
1. list_replays(project="web", filter="url:/checkout")
→ Returns replays matching the URL
2. get_replay(replay_id=...)
→ Returns console logs, network requests, user interactions
3. get_replay_console_logs(replay_id=...)
→ Shows the JavaScript errors during the session
4. Identifies the failing API call, the console error, and the user action
5. Surfaces diagnosis + suggested fix
The agent "watches" the user's session, reads the console logs, and identifies the failure point. For visual bugs (layout issues, broken interactions), the Replay tool exposes the user-session recording as a navigable timeline.
Source Maps + Decoded Stack Traces
For production JavaScript apps with minified bundles, the source-map integration is essential:
| Tool | What It Does |
|---|---|
get_source_map_debug_id | Get the debug ID for a release's source maps |
resolve_source_file | Resolve a minified frame to its source-mapped file + line |
The agent reads the stack trace, resolves each frame to its original source file and line, and proposes a fix in the actual codebase. No more "fix line 1 of bundle.js" — instead, fix line 42 of src/checkout/payment.ts.
For teams shipping minified JavaScript or React Native apps, this is the difference between "we have an error in our app" and "we have an error in our codebase, on line 42."
Issue Sync: Linear/Jira/GitHub in the Loop
Sentry's issue-sync to Linear, Jira, GitHub, and Azure DevOps is fully exposed via MCP:
User: "Triage the top 10 Sentry issues and file Linear tickets for each
that doesn't already have a linked issue."
Agent:
1. list_issues(project="api", sort=freq, limit=10)
2. For each issue:
a. get_issue → check if already linked to Linear
b. If not, link_issue_to_linear(linear_team_id, linear_issue_id)
c. Or create a new Linear issue via Linear MCP, then link
3. Returns a triage report
The integration closes the loop: Sentry detects the error, the agent triages, Linear tracks the work, GitHub hosts the fix PR, Sentry verifies the fix in the next release. End-to-end production-debugging workflow, fully agent-driven, with HITL approval at each destructive step.
Facio Integration
{
"mcpServers": {
"sentry": {
"command": "npx",
"args": ["-y", "@sentry/mcp-server"],
"env": {
"SENTRY_AUTH_TOKEN": "${credentials.SENTRY_AUTH_TOKEN}",
"SENTRY_ORG": "acme",
"SENTRY_DEFAULT_PROJECT": "api"
}
}
}
}
Facio's audit trail captures every Sentry MCP call with the tool, the project, the issue, the action, and the result. For a regulated team (SOC2, ISO 27001), this is the complete production-debugging record: "Agent at 14:32 UTC analyzed issue PROD-1234, fetched 12 events, requested Seer analysis, applied autofix to PR #567, verified release health."
For HITL workflows, the tool annotations map to gate requirements:
| Tool | Severity | Suggested Gate |
|---|---|---|
list_*, get_*, search_* | Read | None — autonomous |
resolve_issue, assign_issue, update_issue | Write, low risk | Soft confirm |
link_issue_to_linear, link_issue_to_github | Write, contextual | Soft confirm |
apply_seer_fix (opens PR) | Write, destructive in effect | Hard confirm (PR goes to team) |
delete_* (rare in Sentry) | Write, destructive | Hard confirm |
The apply_seer_fix tool deserves special attention — it's the agent opening a PR based on AI analysis. Facio should require hard confirmation with the user reviewing the suggested patch before the PR is filed. The fix is AI-generated; the human takes responsibility.
For multi-org or multi-project setups (one Sentry org per environment, per product line, per customer), the pattern is one MCP server per org with its own auth token. The agent switches context per org, the audit trail is per-org, and the HITL gating is per-org.
For Sentry's EU region (sentry.io vs self-hosted.de.sentry.io), the same pattern works — just point the MCP server at the right endpoint. No special EU-vs-US server configuration needed; Sentry's MCP server respects the org's data residency.
Quickstart
# 1. Get a Sentry auth token
# https://sentry.io/settings/account/api/auth-tokens/
# Scopes: project:read, project:write, event:read, org:read
# 2. Install the MCP server
npm install -g @sentry/mcp-server
# 3. Configure your MCP client
{
"mcpServers": {
"sentry": {
"command": "npx",
"args": ["-y", "@sentry/mcp-server"],
"env": {
"SENTRY_AUTH_TOKEN": "sntrys_...",
"SENTRY_ORG": "acme",
"SENTRY_DEFAULT_PROJECT": "api"
}
}
}
}
# 4. First prompts
# "What are the top 5 unresolved errors in our API project?"
# "Investigate the /api/checkout endpoint — why is it throwing 500s?"
# "We deployed v1.2.3 yesterday. Did it cause any new issues?"
# "Why is /api/checkout taking 2.3s when it used to take 400ms?"
# "Triage the top 10 Sentry issues and link any that need Linear tracking"
Use Cases
Production debugging: "Production is on fire. /api/checkout is throwing 500s. Find the cause." List issues → get stack trace → Seer analysis → suggested fix → PR.
Deployment impact reports: "We deployed v2.0.0 yesterday. Show me the impact." Release health + new issues + frequency comparison + user impact estimate.
Regression detection: "Did v2.0.0 introduce any regressions?" Compare release health + first-seen issues + crash rate delta + affected users.
Performance optimization: "Find the slowest API endpoints and propose fixes." List transactions → sort by p95 → get slow spans → suggest indexes / caching / query rewrites.
Frontend bug investigation: "Customer says checkout doesn't work on mobile." Filter replays by URL → get console logs → identify failing API call → propose fix.
Triage automation: "Triage the top 20 Sentry issues, resolve duplicates, assign owners, link Linear tickets." Full triage loop.
Cross-tool correlation: "Show me all Sentry issues affecting our iOS app, grouped by the Linear project they're linked to." Multi-source correlation.
Release readiness check: "Before we deploy v2.1.0, are there any unresolved errors in the code paths it's touching?" Issue check against upcoming release files.
Onboarding new engineers: "Show me the most common errors a new backend engineer would see on call." Top issues + sample stack traces + runbook links.
Compliance audit: "List every unresolved PII-leak error in the last 90 days, with affected users and remediation status." Filtered issue list for compliance reporting.
Postmortem generation: "Generate a postmortem for the May 14 outage: timeline, root cause, affected users, current remediation status." Multi-source aggregation.
A/B test monitoring: "Monitor the new checkout flow. Are error rates higher for users on variant B vs A?" Release-filtered issue comparison.
Bottom Line
The Sentry MCP Server is the production-observability default for AI agents in 2026. ~22 tools covering the full production-debugging workflow — issues, events, releases, performance, replays, Seer AI analysis, source-map resolution, issue sync. MIT-licensed. Maintained by Sentry. Backed by Seer, Sentry's own AI root-cause-analysis agent.
For any agent that touches production code — on-call rotation, incident response, performance optimization, deployment validation, customer bug investigation — this is the missing layer. The agent reads the errors, fetches the events, runs Seer analysis, and proposes the fix. The human reviews, approves, and the fix goes out.
For the broader MCP ecosystem, Sentry's pattern is the design lesson every "observability-as-MCP" server should copy. Production observability needs both fast reads (issues, events, traces) and AI analysis (root-cause, suggested fixes). The MCP server should expose both, with the same authentication model and the same audit trail. When the agent can debug production end-to-end, it's no longer a sidekick — it's a teammate.
npx -y @sentry/mcp-server with SENTRY_AUTH_TOKEN=sntrys_... and your agent has production observability.
MCP Spotlight is a series covering servers that give AI agents real capabilities. Every server is evaluated for design clarity, ecosystem fit, and integration fit with Facio's HITL-first agent runtime.