Fetches and analyzes issues from Sentry, combines with Ruby codebase analysis to provide comprehensive insights, stack trace analysis, and fix suggestions for Ruby applications.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sentry-investigator investigate issue ATS-3YJ"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that automatically reads Sentry issues, investigates them by analyzing your Ruby codebase, explains why issues happened, and provides fix suggestions tailored for Ruby applications.
š Sentry Integration: Fetch and analyze issues directly from your Sentry projects
š Ruby-Focused Analysis: Specialized support for Ruby, Rails, and ERB files
š Codebase Analysis: Automatically analyze your Ruby code to understand issue context
š§ Smart Investigation: Combine Sentry data with Ruby code analysis for comprehensive insights
š§ Ruby Fix Suggestions: Get specific, actionable fix recommendations for Ruby errors
š Impact Analysis: Understand user impact and frequency patterns
ā” Stack Trace Analysis: Deep dive into Ruby stack traces with code context
Related MCP server: mcp-sentry
Node.js 18 or higher
A Sentry account with API access
Ruby/Rails project (primary focus)
Cursor editor (or any MCP-compatible client)
Clone or download this MCP server:
git clone https://github.com/doraemon0905/sentry-mcp
cd sentry-mcpInstall dependencies:
npm installBuild the project:
npm run buildGo to Sentry (https://your_domain.sentry.io) ā Settings ā Personal Tokens
Create a new token with the following scopes:
org:read
project:read
event:read
alerts:read
team:read
Add the MCP server to your Cursor configuration. Edit your MCP settings file:
On macOS/Linux: ~/.cursor/mcp.json
On Windows: %APPDATA%\Cursor\mcp.json
{
"mcpServers": {
"sentry-investigator": {
"command": "node",
"args": ["/path/to/sentry-mcp/dist/index.js"],
"env": {
"SENTRY_AUTH_TOKEN": "your-sentry-auth-token-here",
"SENTRY_ORGANIZATION": "your-sentry-org-slug",
"SENTRY_PROJECT": "your-default-project-slug"
}
}
}
}Required Environment Variables:
SENTRY_AUTH_TOKEN: Your Sentry API token
SENTRY_ORGANIZATION: Your Sentry organization slug
SENTRY_PROJECT: (Optional) Your default project slug
Replace /path/to/sentry-mcp with the actual path to this project.
Restart Cursor to load the new MCP server.
Use the get_sentry_issues tool to fetch recent issues:
- project: (optional) Specific project slug
- limit: Number of issues (default: 10, max: 100)
- status: unresolved, resolved, or ignored (default: unresolved)Use the investigate_issue tool with:
- issue_id: The Sentry issue ID
- codebase_path: Path to your Ruby codebase (default: current directory)
- include_fix: Whether to include fix suggestions (default: true)Use the analyze_stack_trace tool to analyze any Ruby stack trace:
- stack_trace: The stack trace text
- codebase_path: Path to your Ruby codebase (default: current directory)Tool | Description |
| Fetch recent issues from Sentry |
| Full investigation of a specific issue (supports short IDs like "ATS-3YJ") |
| Analyze any stack trace with Ruby code context |
When you investigate a Ruby issue, you'll get a comprehensive report including:
# š Issue Investigation Report
**Issue:** NoMethodError: undefined method `name' for nil:NilClass
**ID:** 12345 (PROJ-1AB)
**Status:** unresolved
**Level:** error
**Occurrences:** 45 (12 users affected)
**First Seen:** 2024-01-15 10:30:00
**Last Seen:** 2024-01-20 15:45:00
## š Stack Trace Analysis
**Parsed Stack Trace:**
1. `get_user_data`
š app/services/user_service.rb:25
### š `app/services/user_service.rb` (Line 25)
```ruby
23: def get_user_data(user_id)
24: user = User.find_by(id: user_id)
ā 25: user.name # Error occurs here
26: endš§ Function: get_user_data
Error Type: NoMethodError
Ruby error caused by trying to call a method on a nil object.
Frequency Analysis: Medium frequency (9 occurrences/day) Impact Level: š” Medium (12 users affected)
# Add method existence checks
if user.respond_to?(:name)
user.name
else
# Handle missing method case
end
# Or use safe navigation
user&.namesrc/
āāā index.ts # Main MCP server entry point
āāā services/
ā āāā SentryService.ts # Sentry API integration
ā āāā CodebaseAnalyzer.ts # Ruby-focused code analysis utilities
ā āāā IssueInvestigator.ts # Main investigation logicThe MCP is optimized for Ruby applications and includes:
File Types: .rb, .erb, .rake files
Stack Trace Parsing: Ruby-specific error format recognition
Method Detection: Ruby method definitions (def, self., lambdas, procs)
Import Analysis: require, require_relative, include, extend, gem statements
Error Types: NoMethodError, NameError, ArgumentError, TypeError, etc.
Fix Suggestions: Ruby-specific error handling patterns
npm run build - Build the TypeScript project
npm run dev - Build in watch mode for development
npm start - Run the built server
npm install
npm run buildFork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request
MIT License - see LICENSE file for details.
"Sentry service not configured"
Ensure SENTRY_AUTH_TOKEN and SENTRY_ORGANIZATION environment variables are set in your MCP configuration
Verify your API token has the correct permissions
"No project specified and no default project configured"
Either specify a project in the tool call or set SENTRY_PROJECT environment variable
"Failed to connect to Sentry"
Check your API token and organization slug
Ensure your network allows HTTPS requests to sentry.io
"File not found in codebase"
Verify the codebase_path parameter points to your Ruby project root
Some files in stack traces may be from gems or external libraries
The analyzer prioritizes Ruby files (.rb, .erb, .rake) over other file types
Stack trace parsing is optimized for Ruby error formats
Method suggestions focus on Ruby patterns and best practices
Excludes common Ruby directories (vendor/, tmp/) from analysis
Analyze a stack trace and find related code in the codebase
| Name | Required | Description | Default |
|---|---|---|---|
| stack_trace | Yes | Stack trace to analyze | |
| codebase_path | No | Path to the codebase to analyze (default: current directory) | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It only states the high-level action but does not mention whether the tool is read-only, whether it requires network access, or what side effects (if any) occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively captures the tool's purpose. It is appropriately sized and front-loaded, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should hint at what the tool returns (e.g., matched code snippets, file paths). It does not, leaving the agent uncertain about the output format or behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters are described in the schema). The tool description adds no additional parameter-level context, meeting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing a stack trace and finding related code in the codebase. It distinguishes from siblings by focusing on code analysis rather than ticket creation or issue retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'investigate_issue' or 'create_jira_from_sentry'. It does not mention typical scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Jira ticket directly from a Sentry issue with automatic linking and rich context
| Name | Required | Description | Default |
|---|---|---|---|
| sentry_issue_id | Yes | Sentry issue ID to create Jira ticket from | |
| board_id | Yes | Jira board ID where the ticket should be created | |
| issue_type | Yes | Jira issue type ID | |
| priority | No | Issue priority (e.g., High, Medium, Low) | |
| custom_summary | No | Custom summary (optional, will use Sentry issue title if not provided) | |
| additional_description | No | Additional description to append to the auto-generated content | |
| labels | No | Array of labels to add to the ticket |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions automatic linking and rich context but fails to explain what that entails (e.g., what gets linked, permissions needed, side effects). The behavioral details are insufficient for an agent to understand the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. It is not verbose, but it lacks structure (e.g., no bullet points). Acceptable for a short description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain return values, error conditions, or side effects. It does not mention what the tool returns or what happens upon successful creation. Completeness is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema (e.g., implies auto-generated content from Sentry). No significant enhancement of parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: create a Jira ticket from a Sentry issue with automatic linking and rich context. It distinguishes itself from siblings like create_jira_ticket (generic) and get_* tools (retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a Sentry issue exists and a linked Jira ticket is needed, but it does not explicitly state when to use this tool versus alternatives (e.g., create_jira_ticket for non-Sentry issues). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Jira ticket from a Sentry issue and link them together
| Name | Required | Description | Default |
|---|---|---|---|
| board_id | Yes | Jira board ID where the ticket should be created | |
| summary | Yes | Ticket summary/title | |
| description | Yes | Detailed description of the issue | |
| issue_type | Yes | Jira issue type ID (use get_issue_types to find available types) | |
| priority | No | Issue priority (e.g., High, Medium, Low) | |
| labels | No | Array of labels to add to the ticket | |
| sentry_issue_url | No | URL of the Sentry issue to link | |
| sentry_issue_id | No | Sentry issue ID to link back to (creates bidirectional link) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses creation and linking behavior, but does not mention side effects (e.g., failed linking, permissions required, or whether it modifies existing tickets). The 'link them together' statement is vague about bidirectional linkage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 13 words, front-loading the core purpose with no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is minimal. It does not explain return values, error cases, or prerequisites (e.g., using 'get_jira_boards' and 'get_issue_types' first). The schema hints at these, but the description adds little context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema; the linking behavior is already implied by the 'sentry_issue_url' and 'sentry_issue_id' parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('Jira ticket from a Sentry issue'), and clearly states the linking behavior. It distinguishes from siblings like 'analyze_stack_trace' and 'get_issue_types' by focusing on ticket creation with a Sentry connection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating Jira tickets linked to Sentry issues, but provides no explicit guidance on when not to use it or alternatives (e.g., 'create_jira_from_sentry'). It lacks exclusion criteria or best-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available issue types for a Jira project
| Name | Required | Description | Default |
|---|---|---|---|
| project_key | Yes | Jira project key (e.g., PROJ) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states what the tool does (a read operation) but lacks details about authentication, rate limits, or side effects. The description adds minimal value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that is concise and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks any explanation of return values or behavior. Without an output schema, the description should clarify what 'issue types' refers to (e.g., a list of names/IDs). The absence of usage context also reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'project_key', so the baseline is 3. The description does not add any additional meaning beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'available issue types', and the context 'for a Jira project'. It differentiates itself from sibling tools like create_jira_ticket and investigate_issue by being a read-only lookup operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when it should not be used. It simply states the function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of available Jira boards for ticket creation
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the purpose and does not disclose traits such as read-only nature, pagination, data freshness, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the essential purpose with no extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is minimally adequate. It explains what is returned (list of available Jira boards) but lacks details about the structure or fields of each board, which could be helpful for subsequent tool calls.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (input schema is empty). The description adds value beyond the schema by explaining the purpose of the result set, which aligns with the baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving available Jira boards specifically for ticket creation. The verb 'Get' and resource 'available Jira boards' are specific, and the context differentiates it from sibling tools like create_jira_ticket or get_issue_types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before creating a ticket ('for ticket creation') but does not explicitly state when to use this tool versus alternatives like get_issue_types. There is no mention of when not to use it or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch recent issues from Sentry for investigation
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Sentry project slug (optional, uses default if not provided) | |
| limit | No | Number of issues to fetch (default: 10, max: 100) | |
| status | No | Issue status filter (unresolved, resolved, ignored) | unresolved |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'Fetch', implying a read operation, but omits details like whether it's safe, side effects, authorization needs, or response characteristics. Minimal transparency beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it might be too concise, missing important context that could be added without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (3 optional params, no output schema), the description is minimal. It lacks context on what 'recent' means, default behavior, and how it fits with sibling tools. Incomplete for an agent to fully understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond what the schema already provides for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Fetch recent issues') and the resource ('from Sentry'), with a purpose hint ('for investigation'). However, it does not differentiate this tool from siblings like `investigate_issue` or `analyze_stack_trace`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. The phrase 'for investigation' is vague and does not specify contextual prerequisites or when to choose this over sibling tools like `analyze_stack_trace`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Investigate a specific Sentry issue by analyzing the codebase and providing explanations and fixes
| Name | Required | Description | Default |
|---|---|---|---|
| issue_id | Yes | Sentry issue ID to investigate (supports both full IDs like "4567890123" and short IDs like "ATS-3YJ") | |
| codebase_path | No | Path to the codebase to analyze (default: current directory) | . |
| include_fix | No | Whether to provide code fix suggestions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool 'analyzes the codebase' but does not clarify what that entails (e.g., file reading, network calls), nor does it mention side effects, permissions, or output characteristics. This lack of detail hinders safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence that efficiently conveys the tool's main action. It avoids unnecessary words but could be more structured to separate purpose, behavior, and output. Still concise for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain what the agent receives (e.g., formatted output, code changes) and any runtime considerations. It only mentions 'explanations and fixes' vaguely. For a tool with moderate complexity, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all three parameters with descriptions, achieving 100% coverage. The tool description merely restates the schema's purpose without adding new meaning or context (e.g., it does not explain how issue_id formats affect analysis or how codebase_path influences results). Baseline score 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool investigates a Sentry issue by analyzing the codebase and providing explanations and fixes. It uses a specific verb-resource pair and hints at its purpose relative to sibling tools like analyze_stack_trace or get_sentry_issues, though it could more explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as analyze_stack_trace or get_sentry_issues. The description does not mention prerequisites, context, or exclusion criteria, leaving the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0analyze_stack_tracecreate_jira_from_sentrycreate_jira_ticketget_issue_typesget_jira_boardsget_sentry_issuesinvestigate_issueThe set has two tools for creating Jira tickets from Sentry issues (create_jira_from_sentry and create_jira_ticket) that are nearly identical in purpose, causing ambiguity. Additionally, analyze_stack_trace and investigate_issue have some overlap in context analysis, though not exact duplicates.
Most tools follow a verb_noun pattern, but 'create_jira_from_sentry' introduces a preposition, and the two Jira creation tools use different naming structures despite similar functions, leading to inconsistency.
With 7 tools covering Sentry issue retrieval, analysis, and Jira ticket creation, the count is well-scoped for the server's purpose without being too sparse or bloated.
The tools cover the primary workflow of investigating Sentry issues and creating Jira tickets, but there are minor gaps such as missing updates to tickets or listing Jira projects, and redundancy reduces overall completeness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI-powered codebase analysis ā call graphs, security, dead code, complexity. 150+ tools.
Investigate errors, track deployments, analyze performance, and manage application monitoring
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vibe-Code-Agent/sentry-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
