sentry-self-hosted-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SENTRY_HOST | Yes | Your Sentry URL (e.g., https://sentry.example.com) | |
| SENTRY_TOKEN | Yes | Auth token with org:read, project:read, event:read scopes | |
| SENTRY_ORG_SLUG | Yes | Organization slug (e.g., my-org) |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_eventA | Get detailed information about a specific Sentry event by project slug and event ID. Returns exception details, stacktrace, tags, and context. |
| get_issueB | Get information about a Sentry issue by its numeric ID or short ID (e.g. "PAYOUT-123"). Includes status, event count, first/last seen. |
| get_latest_eventB | Get the latest event for a Sentry issue. |
| list_issuesB | List Sentry issues with optional filters. Supports search queries like "is:unresolved", "level:error", etc. |
| list_projectsA | List all Sentry projects in the organization. |
| get_stack_framesA | Extract and format stack frames from a Sentry event. Useful for quickly seeing the call chain without full event details. |
| get_issue_with_stacktraceB | Get issue metadata and latest event stacktrace in a single call. |
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 7 tools
Most tools have distinct purposes: list vs. get, issue vs. event vs. stacktrace. Some minor overlap exists between get_event and get_stack_frames, as both return stacktrace data, but they are differentiated by level of detail and formatting.
All tool names follow a consistent verb_noun pattern using snake_case. The 'get_' and 'list_' prefixes clearly indicate action type, and resource names are used uniformly across the set.
With 7 tools, the server is well-scoped for a read-only Sentry debugging workflow. Each tool provides a meaningful view into issues and events without unnecessary bloat or redundancy.
The tool surface covers exploration and retrieval well, including issues, events, stacktraces, and projects. However, it lacks any mutating operations (e.g., updating issue status, resolving issues) and has no way to list all events for an issue, which could create dead ends in a complete debugging workflow.