---
name: sentry-essentials
description: Ground rules for using Sentry through the Sentry MCP server, covering resolving the organization and project, writing Sentry search queries, reading issue details before concluding and asking before changing issues or projects. Use when the user asks for anything in Sentry and no more specific Sentry skill fits.
---

# Working with Sentry

## Orient

- `whoami` shows the signed-in user. `find_organizations`, `find_teams` and `find_projects` resolve names to slugs. Ask when several projects match; staging and production are often separate projects.
- Sentry issue ids look like `PROJECT-1A2B`, or a Sentry URL. Accept both.

## Search well

- `find_issues` takes Sentry search syntax, such as `is:unresolved`, `level:error`, `firstSeen:-24h`, `release:1.4.2`, `environment:production` and `assigned:me`. Sort by frequency or users affected for impact, or by first seen for new problems.
- `find_errors` searches individual error events; `find_transactions` searches performance data.
- `find_tags` shows which tags exist, such as browser, release or customer, so you can split an issue by them.

## Reading

Read `get_issue_details` before saying what an issue is: the stack trace, breadcrumbs, tags and first and last seen. Do not diagnose from the title alone.

## Docs

`search_docs` and `get_doc` answer "how do I set up or configure Sentry" questions from Sentry's own documentation.

## Changes need a yes

`update_issue` (resolve, ignore, assign), `create_team`, `create_project`, `update_project` and `create_dsn` change Sentry. Show the exact change and get the user's explicit yes first.