MCP field guide / Sentry
// mcp field guide · observability
The honest one. Sentry's MCP is almost entirely read, diagnose, and triage — inspect errors, walk stack traces, run root-cause analysis, resolve issues. There's very little to break, so a guard mostly stays out of the way. We'll tell you exactly where it does and doesn't help.
GUARD FIT · READ + TRIAGE (dominant)
LOWInspecting issues/traces and resolving/assigning are read or trivially-reversible. Nothing to compensate — a guard here is friction, not safety.
GUARD FIT · WRITE TAIL
SELECTIVEOne truly irreversible tool (delete_uptime_monitor) plus org-shaping config/provisioning writes are worth a gate. That's the whole case.
Overall fit: MODERATE — and honestly weak relative to the read-heavy reality. This is a server where we're not the hero, and we'll say so.
getsentry/sentry-mcp (npm @sentry/mcp-server, v0.37.0) is Sentry's own official server — a hosted endpoint at mcp.sentry.dev/mcp (OAuth, scoped by org or project) plus a local stdio build. It connects coding agents to Sentry's error-tracking and observability data: issues, events, stack traces, traces/spans, releases, replays and profiles, and it turns plain-English queries into Sentry's search syntax. Sentry describes its tool selection as deliberately "focused on developer workflows and debugging use cases, rather than a general-purpose MCP server for all Sentry functionality."12
Names from the v0.37.0 source catalog. The large majority are read-only; only a handful mutate, and exactly one deletes.3
| Tier | Examples |
|---|---|
| read-only | whoami, find_projects, get_issue_details, get_event_stacktrace, get_trace_details, get_span_details, search_events, search_issues, analyze_issue_with_seer, search_docs… |
| mutating | update_issue (resolve / assign / archive), add_issue_note, create_project, create_team, create_dsn, create_uptime_monitor, update_project, add_team_to_project, remove_team_from_project |
| destructive | delete_uptime_monitor — the only hard delete; its own description says "Deletion cannot be undone." |
Honest finding: there is no delete_project, delete_team, or delete_issue in the v0.37.0 catalog. remove_team_from_project is a reversible association change, not a hard delete. The destructive surface here is genuinely tiny — one tool.
In-editor debugging assistant. Paste an issue ID; the agent pulls get_issue_details + get_event_stacktrace + get_trace_details, then analyze_issue_with_seer for a root-cause hypothesis — all read-only.
Natural-language triage. "Top new unresolved crashes in checkout, last 24h" → search_issues, then update_issue to assign or archive.
Release regression check. Correlate an error spike with a recent deploy via find_releases + get_release_details — reporting, no changes.
Plainly: for the dominant use — inspecting issues and traces, running Seer, triaging — a guard adds little to no value. There's nothing to compensate or undo, and gating reads is pure friction. This is a good example of a server where a ChronoMCP-style guard is not the hero, and pretending otherwise would undercut every other page in this guide.
The guard earns a place only on the thin write tail:
delete_uptime_monitor — explicitly irreversible per its own description. The one clear per-tool case.create_project/create_team/create_dsn, update_project/update_dsn, team-to-project changes — reversible, but they reshape the org.update_issue/add_issue_note — triage that's trivially reversible (re-open, edit).The takeaway: match the control to the risk. A read/diagnostic MCP like this one mostly wants to be left alone; save the human checkpoint for the one irreversible delete and the org-shaping writes. That calibration — gating what's dangerous and only what's dangerous — is the whole idea. See how the guide grades each server.
ChronoMCP passes the reads through and gates only the destructive tail — so a low-risk server stays low-friction.
Read the quickstart → More MCP profilesgetsentry/sentry-mcp (repo): github.com/getsentry/sentry-mcpProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with Sentry. Tool names are derived from the v0.37.0 source catalog; risk groupings are our classification. Capabilities reflect sources current as of Aug 2026 and can change — check the source links for the latest.