Back to blog

Engineering · Jul 1, 2026

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

The official Sentry MCP Server — ~22 tools (issues, events, releases, performance, replays, source maps, Seer AI root-cause analysis, issue sync to Linear/Jira/GitHub). MIT-licensed, GA, official Sentry-maintained. The production-observability default for AI agents in 2026.

MCP ServerSentryError TrackingSeer AIObservabilityAI Agents

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:

CategoryToolsPurpose
Issueslist_issues, get_issue, update_issue, resolve_issue, assign_issueTriage and lifecycle
Eventsget_event, get_latest_event, list_events, get_stacktraceRead errors and traces
Projectslist_projects, get_project, list_project_membersWorkspace navigation
Releaseslist_releases, get_release, get_release_health, create_releaseDeployment tracking
Performancelist_transactions, get_transaction, get_trace_details, get_performance_summaryLatency + throughput
Replayslist_replays, get_replay, get_replay_console_logsUser-session playback
Source Codeget_source_map_debug_id, resolve_source_fileDecoded stack frames
AI Analysisanalyze_issue_with_seer, get_seer_fix_suggestion, apply_seer_fixSentry's own AI debugging
Issue Synclink_issue_to_linear, link_issue_to_jira, link_issue_to_github, unlink_issueCross-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:

ToolWhat It Does
list_releasesList all releases with commit metadata, deploy time, author
get_releaseGet release details: commits, files changed, associated issues
get_release_healthCrash-free session rate, crash-free user rate, adoption
get_release_files_changedDiff 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:

ToolWhat It Does
list_transactionsList all transaction endpoints with p50/p95/p99 latency
get_transactionDetailed transaction breakdown: spans, DB queries, external calls
get_trace_detailsFull distributed trace across services
get_performance_summaryAggregated 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:

ToolWhat It Does
get_source_map_debug_idGet the debug ID for a release's source maps
resolve_source_fileResolve 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:

ToolSeveritySuggested Gate
list_*, get_*, search_*ReadNone — autonomous
resolve_issue, assign_issue, update_issueWrite, low riskSoft confirm
link_issue_to_linear, link_issue_to_githubWrite, contextualSoft confirm
apply_seer_fix (opens PR)Write, destructive in effectHard confirm (PR goes to team)
delete_* (rare in Sentry)Write, destructiveHard 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.

Keep reading

More on Engineering

View category