selfhosted-sentry-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SENTRY_URL | Yes | Base URL of your self-hosted Sentry instance (e.g., https://your-sentry-instance.com) | |
| SENTRY_ORG_SLUG | Yes | Organization slug (e.g., my-org) | |
| SENTRY_AUTH_TOKEN | Yes | Sentry API token with scopes: issue:read, project:read, event:read, issue:write, comment:write |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_sentry_issueA | Retrieve details for a specific Sentry issue by ID or URL, including the stacktrace from the latest event. Supports filtering and automatic truncation to reduce response size. |
| list_sentry_projectsA | List all projects within the configured Sentry organization. |
| list_sentry_issuesC | List issues for a specific project, optionally filtering by query or status. Supports pagination. |
| list_issuesA | List issues using Sentry search query syntax (e.g., "is:unresolved environment:production"). More powerful than list_sentry_issues which is project-scoped. |
| update_sentry_issue_statusC | Update the status of a Sentry issue. |
| create_sentry_issue_commentB | Add a comment to a Sentry issue. |
| get_issue_hashesA | Get the fingerprint hashes for an issue. Useful for understanding why events are grouped together. |
| bulk_update_issuesB | Bulk update multiple issues at once (resolve, ignore, unresolve, assign). Useful for triaging many issues. |
| get_sentry_event_detailsB | Retrieve details for a specific event ID within a project. IMPORTANT: For large events, always use limit parameter (e.g., limit: 10) to avoid token limits. |
| list_issue_eventsB | List all events for a specific issue. Useful to see all occurrences of an error over time. |
| list_error_eventsA | List error events in a project. Search across all events without knowing the issue ID. |
| get_stack_framesB | Extract structured stack trace frames from an event. Optimized for debugging. |
| check_dsym_statusA | Check if debug symbols (dSYM files) are missing for iOS/macOS crashes. |
| list_breadcrumbsB | Extract all breadcrumbs from an event, showing the trail of events leading up to an error. |
| list_releasesB | List releases in the organization. Releases link code deployments to error data. |
| get_release_detailsB | Get detailed information about a release including health stats, commits, and authors. |
| list_teamsA | List all teams in the organization. |
| get_issue_tagsB | List all tags captured for an issue. Tags help identify patterns (e.g., environment, OS, user segment affected). |
| get_issue_tag_valuesA | Get tag value distribution for a specific tag key. Shows which values occur most frequently for an issue. |
| list_activityB | List activity log for an issue. Shows comments, assignments, status changes, and other events. |
| get_trace_detailsA | Get distributed trace details with full span tree and timing information. Requires Performance data. |
| get_grouping_configA | Get the fingerprinting rules and grouping configuration for an issue. Shows why events are grouped together. |
| merge_issuesA | Merge multiple issues into one by fingerprint hash. Use after identifying that separate issues should be grouped together. |
| raw_sentry_apiA | Make a raw API call to any Sentry endpoint. Returns unfiltered JSON. WARNING: Event endpoints can return 100K+ tokens. Use grep_pattern for events. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 24 tools
Each tool has a clearly distinct purpose. Even tools that might seem overlapping, like list_issues and list_sentry_issues, are differentiated by scope and query syntax. No two tools appear to do the same thing.
All tool names use snake_case and follow a verb_noun pattern. The only minor inconsistency is 'raw_sentry_api', where 'raw' is an adjective rather than a verb, but it remains clear and readable.
With 24 tools, the set is slightly above the ideal range but still well-scoped for a comprehensive Sentry integration. Each tool serves a distinct function, and there is no padding.
The tool surface covers most essential operations for Sentry issue and event management, including listing, updating, merging, and inspecting details. Minor gaps like user management or alert configuration are acceptable given the server's focus on error tracking.