Sentry’s official MCP server. The agent gets read access to your Sentry projects — issues, events, stack traces, breadcrumbs, release tagging. It’s the difference between “Sentry sent me an alert, I’ll go investigate” and “Claude, what broke after the v2.5.0 deploy and propose a fix.”
What it produces: structured tools for list_issues, get_issue, search_events, get_stack_trace, list_releases. Filter by project, environment, time window, severity. Stack traces returned with source-mapped frames if you’ve uploaded sourcemaps.
Best for: post-deploy incident triage, regression hunting (“which commit introduced this error class?”), and on-call automation where the first response is “agent fetches the trace, identifies the failing module, drafts a fix PR.”
Skip if: you don’t run Sentry — the MCP is Sentry-specific. Skip if you only have one project and check it manually weekly; the MCP shines at scale (5+ projects, daily error volume).
Setup gotchas: auth token from Sentry → User Settings → Auth Tokens, with project:read and event:read scopes minimum. SENTRY_AUTH_TOKEN env var. Sentry’s API rate-limits aggressively — the MCP handles 429s with backoff, but a chatty agent run can still hit ceilings on small plans. Cache results during a debugging session if you hit limits.
Real-world workflow: post-deploy ritual. After every production push, an agent calls list_issues since=last_release and reports new error classes (not new occurrences of known errors — that’s noise). If new error class found, fetch stack trace, identify the failing module, propose a one-line revert or a forward fix. 3 minutes of agent time replaces a 15-minute manual scan.
Compatible alternatives: Cloudflare MCP for edge-runtime errors that don’t reach Sentry, GitHub MCP Server to immediately open the fix PR after diagnosis.
Pair with a “new error class” filter — without it, the noise floor will drown the signal.