1---2name: sentry-53description: Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data through the Sentry MCP tools.4---5
6
7# Sentry MCP Observability
8
9## Quick start
10
11- Use Sentry MCP tools only. Do not call local Python helpers, direct REST scripts, or `SENTRY_AUTH_TOKEN` workflows for issue/event inspection.
12- Prefer issue URL input when the user provides it; MCP can extract org, project, and issue identifiers directly.
13- Defaults: time range `24h`, environment `prod`, limit 20 unless the user specifies otherwise.
14- Use MCP-native issue IDs, event IDs, trace IDs, and org/project slugs when present; do not invent fallbacks.
15
16## Core tasks
17
18### 1) Specific issue or URL
19
20- Use `mcp__sentry__get_issue_details` for a known issue ID, event ID, or full Sentry issue URL.
21- Use `mcp__sentry__search_issue_events` to filter events within that issue by time, environment, release, user, or trace.
22- Use `mcp__sentry__get_issue_tag_values` for aggregate distributions such as affected URLs, browsers, environments, or releases.
23
24### 2) Search across issues
25
26- Use `mcp__sentry__search_issues` when the user wants a list of grouped issues or user feedback.
27- Use `mcp__sentry__search_events` for counts, aggregates, or raw event/log/span search.
28- Use `mcp__sentry__find_organizations`, `mcp__sentry__find_projects`, and `mcp__sentry__find_teams` only to discover identifiers that are missing.
29
30### 3) Deeper analysis
31
32- Use `mcp__sentry__analyze_issue_with_seer` only when the user explicitly asks for Seer analysis or the root cause is not recoverable from issue details alone.
33- Use `mcp__sentry__get_trace_details` for trace overview by trace ID.
34- Use `mcp__sentry__find_releases` when the user asks about recent releases or release deployment timing.
35
36## Output rules
37
38- State which MCP tool path was used when the distinction matters, especially `search_issues` versus `search_events`.
39- For issue summaries: include title, issue ID, status, impact counters, last seen, and the strongest culprit evidence available.
40- For event summaries: include timestamp, environment, release, culprit, and relevant tags.
41- Redact PII in responses. Avoid dumping raw stack traces unless the user explicitly asks.
42- If identifiers are ambiguous, say what is missing and use the narrowest discovery tool needed.
43- If the user supplies a Sentry URL, preserve the full URL and pass it through unchanged.
44
45## Local Cross-References
46
47- `ios-testflight-triage` - Use to align external crash trends with TestFlight crash investigation workflows.
48- `ios-app-store-connect-ref` - Use when comparing Sentry data against App Store Connect crash reports.