MCP Sentry
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| auth_token | Yes | Your Sentry authentication token | |
| project_slug | Yes | Your Sentry project slug | |
| organization_slug | Yes | Your Sentry organization slug |
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": false
} |
| prompts | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_sentry_issueA | Retrieve and analyze a Sentry issue by ID or URL. Use this tool when you need to: - Investigate production errors and crashes - Access detailed stacktraces from Sentry - Analyze error patterns and frequencies - Get information about when issues first/last occurred - Review error counts and status |
| get_list_issuesA | Retrieve and analyze Sentry issues by project slug. Use this tool when you need to: - Investigate production errors and crashes - Access detailed stacktraces from Sentry - Analyze error patterns and frequencies - Get information about when issues first/last occurred - Review error counts and status |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| sentry-issue | Retrieve a Sentry issue by ID or URL |
| sentry-issues-by-project | Retrieve Sentry issues by project slug |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools are essentially indistinguishable in purpose. Both descriptions are identical, listing the exact same use cases (investigate errors, access stacktraces, analyze patterns, get timing info, review counts). An agent would have no way to determine when to use get_list_issues versus get_sentry_issue since they appear to serve the same function.
Both tools follow a similar get_ prefix pattern, which provides some consistency. However, the naming is confusingly similar (get_list_issues vs get_sentry_issue) rather than clearly differentiated, and the verb-noun structure is mixed (list_issues vs sentry_issue).
With only 2 tools, this feels severely under-scoped for a Sentry integration. A production error monitoring system would typically need tools for creating issues, updating statuses, searching/filtering, accessing events, or managing projects. Two tools is too few to cover meaningful workflows.
The tool surface is severely incomplete for Sentry's domain. There are no tools for creating issues, updating issue status (resolve/ignore), searching across projects, accessing event details, managing alerts, or any administrative functions. The two existing tools appear redundant rather than complementary.