# Sentry MCP

> Sentry MCP Server gives your AI agent direct access to Application Performance Monitoring data. You can query raw exceptions, read full stack traces, list current errors across projects, and even close bugs directly from your chat window or IDE. It turns complex debugging into simple conversations.

## Overview
- **Category:** loved-by-devs
- **Price:** Free
- **Tags:** error-tracking, performance-monitoring, debugging, stack-trace, incident-management

## Description

You're giving your AI agent direct access to Sentry’s full Application Performance Monitoring stack. You don't have to waste time digging through dense crash dashboards in a browser; your agent pulls raw exceptions and deep data right into your chat or IDE. This server lets you handle complex debugging like it's just a conversation.

**Handling Issues and Bugs:**

The tool `list_issues` runs and reports on every active, recurring error across the specific project scope you define. For any one of those reported issues, you can run `get_issue_details`, which pulls all the contextual data—the full stack trace and all associated metadata—for that single bug ID. Once you've confirmed it's fixed or handled, running `resolve_issue` changes its status in Sentry, marking it as resolved without touching a web UI.

**Tracking System Activity:**

The tool `list_events` generates a rundown of general activity logs that happened recently across the entire project timeline. If you need to dig into one specific log entry, you run `get_event_details` and get every piece of data associated with that single system event. 

**Managing Your Environment:**

You can map out your entire organization's structure using several tools. Run `list_organizations` to get a catalog of every separate Sentry account you manage. Inside those, you use `list_projects` to list all individual software repositories. To see who runs what, run `list_organization_teams` to list every team configured under your main organization account; pairing that with `list_organization_users` gives you a roster of every user associated with the entire Sentry setup.

**Taking Action and Cleanup:**

Beyond viewing data, you have control over maintenance. You can use `delete_issue` to permanently wipe an issue from Sentry—you've gotta be absolutely sure it should vanish before running that one. The combination of these tools means your agent handles everything: listing active errors (`list_issues`), getting deep context on those errors (`get_issue_details`), seeing general activity logs (`list_events`), and managing the entire organizational structure (`list_projects`, `list_organization_teams`, etc.).

## Tools

### delete_issue
This permanently deletes an issue in Sentry. Use this only if you are absolutely sure it should be gone.

### get_event_details
Retrieves all details for a single, specific system event log entry.

### get_issue_details
Pulls every piece of data—the full stack trace and metadata—related to one particular bug issue ID.

### list_events
Generates a list of recent system events across the entire project's operational timeline.

### list_issues
Shows all currently open and recurring issues (errors) within a defined Sentry project scope.

### list_organization_teams
Lists every team configured under your main Sentry organization account.

### list_organization_users
Provides a list of all users associated with the entire Sentry organization.

### list_organizations
Retrieves a catalog of every separate Sentry organization you manage.

### list_projects
Lists all individual software projects (repositories) configured in your Sentry silo.

### resolve_issue
Changes the status of a bug issue to 'resolved,' marking it as handled within Sentry's tracking system.

## Prompt Examples

**Prompt:** 
```
Enumerate the most recently flared active open errors across the 'frontend-ui' project portal in Sentry.
```

**Response:** 
```
I've successfully interrogated the Sentry API via `list_issues` scoping specifically down to the 'frontend-ui' project slug. Your dashboard flags 5 overarching unhandled exceptions aggressively repeating. The paramount threat ranks an ID marking 'TypeError: Cannot read properties of undefined (reading 'auth_token')' with ~4,200 events escalating in merely six hours. Should I invoke the agent to dig deep into this specific issue details block?
```

**Prompt:** 
```
Fetch all pertinent internal parameters regarding issue id 6B3VX4921.
```

**Response:** 
```
After meticulously scanning via `get_issue_details` parameter boundaries, issue block 6B3VX4921 centers around a PostgreSQL Deadlock collision error. The stack trace isolates its organic foundation originating from your `payment_processor.ts` dependency specifically on Line 132. Over 300 users were severely impacted since Tuesday. Noticeably, this fault correlates concurrently with a massive migration you pushed recently.
```

**Prompt:** 
```
I've deployed a patch fixing the deadlock in db.ts. Mutate this specific issue globally to 'resolved'.
```

**Response:** 
```
Got it. I've initiated an asynchronous payload signaling tool `resolve_issue` applied effectively corresponding to your specified ID within the active ecosystem. Subsequent polling shows this entity has correctly adopted the formal status value: 'RESOLVED'. Sentry charts will stop screaming out and notifying on channel hooks.
```

## Capabilities

### List all current project issues
The tool `list_issues` finds and reports on active, recurring errors across a specified Sentry project.

### Get detailed error information
Using `get_issue_details`, the agent pulls all contextual data, including the full stack trace, for one specific issue ID.

### List recent system events
The tool `list_events` retrieves a list of general activity logs that occurred recently in the project.

### Identify organizational components
You can use tools like `list_projects`, `list_organization_teams`, and `list_users` to map out who owns what within your Sentry account.

### Resolve a flagged bug
The tool `resolve_issue` changes the status of an issue in Sentry, marking it as fixed or handled.

## Use Cases

### Debugging a production crash in the CI/CD pipeline
A developer finds an intermittent failure. Instead of waiting for a teammate to manually pull data, they prompt their agent: 'Show me all issues related to user authentication.' The agent runs `list_issues`, pulls one ID with `get_issue_details`, and presents the full stack trace so the dev can write the fix immediately.

### Cleaning up old, fixed bugs
The ops engineer has finished investigating a critical bug. They don't want to navigate back into the web portal. The agent runs `resolve_issue` on the specific ID, closing it and updating the official status without extra steps.

### Auditing project scope before onboarding
A new team member needs visibility across all services. They ask the agent to 'List all projects under this organization.' The agent runs `list_projects` and gives them a clear, structured inventory of every silo they need to know about.

### Correlating errors with user groups
The technical founder suspects only one department is having issues. They ask the agent to 'List all teams.' Then, when an issue pops up, they can narrow the scope by referencing team metadata or running `list_issues` scoped by project.

## Benefits

- Stop manual dashboard clicking. Instead of hunting through web UI tabs, you ask the agent to `list_issues` and get a summary instantly.
- Deep context on failure points. The tool `get_issue_details` feeds the LLM the full stack trace and environment data—no copy-pasting required.
- Triage bugs without logging in. You can use `resolve_issue` to mark an exception as safe, handled work directly through conversation.
- Map your whole infra quickly. Use `list_projects`, `list_organization_teams`, and `list_users` to understand the full structure of your Sentry setup.
- See what just happened. Run `list_events` to get a raw feed of recent activity logs, helping you correlate an error with a specific deployment time.

## How It Works

The bottom line is you don't have to switch apps or navigate dashboards; you just ask your agent to find and analyze the problem.

1. Activate this unified Server in your agent's configuration.
2. Provide your Organization Slug and Auth Token securely to grant access.
3. Ask your AI client a question, like: 'What are the top 5 open errors in the payments project?'

## Frequently Asked Questions

**How do I use list_issues to find active bugs?**
To see current issues, ask your agent to run `list_issues` and specify the project name. This gives you a quick summary of all open errors without needing to navigate the dashboard.

**What is the difference between list_events and list_issues?**
`list_events` provides general system activity logs (like deployments or warnings). `list_issues`, however, focuses specifically on recurring, unhandled software exceptions that signal a true bug.

**Can I close a bug using resolve_issue?**
Yes. You pass the issue ID to the agent and ask it to run `resolve_issue`. This changes the status in Sentry, marking the problem as fixed or handled.

**Does get_issue_details provide the full stack trace?**
Yes. It pulls all contextual data for that specific issue ID, including the entire stack trace and environmental metadata needed to pinpoint the root cause.

**How do I use list_projects to understand my application scope?**
It returns a catalog of every project configured in your Sentry organization. This is critical because it lets you identify the exact project slug needed before running any other debugging tool like `list_issues` or `get_event_details`.

**Does list_organization_users help me track who caused a bug?**
Yes, this tool lists every user within your organization's Sentry environment. You can correlate specific error IDs and stack traces against the user profiles to pinpoint if an issue affects a particular role or employee group.

**Is using delete_issue irreversible?**
It is. `delete_issue` permanently removes the bug report from Sentry's records. Only use this tool when you are 100% certain that the logged exception was erroneous and needs to be purged entirely.

**What credentials do I need for any tool in the Sentry MCP Server?**
You must provide your Organization Slug and a valid Auth Token. These two pieces of information establish the secure boundary (or scope) for all operations, ensuring every action—from listing to resolving—only interacts with data from your company's instance.

**Can this AI integration actually mark errors as fixed?**
Yes. This agent component possesses mutable write access. If you invoke the prompt properly, it will fire the `resolve_issue` tool, marking the corresponding exception ID completely dealt with inside the Sentry ecosystem. It can also erase bugs fully via `delete_issue`.

**What is the difference between inspecting an 'Issue' and an 'Event'?**
An 'Issue' gathers underlying multiple occurrences of the identical stack exception into one overarching master group. In contrast, querying an 'Event' (`get_event_details`) focuses the AI on a strictly singular, point-in-time incidence where the system crashed.

**Do I need to supply the Organization Slug with every command?**
You configure the overarching Organization Slug strictly at startup globally. For project-level filters, let your LLM query `list_projects` first to fetch internal slugs naturally into its memory buffer without constant repeated user inputs.