Commands
/sentry:seerAsk a question about what Sentry is seeing right now — which errors are turning up most, which ones are hitting the most people — and get the answer in words instead of going and reading a dashboard.
Hands an assistant Sentry's own installation steps for whatever language an app happens to be written in, plus the ones for dealing with the errors that follow.
Sentry is where an app's crashes go so that somebody sees them. Getting it in, and then acting on what it collects, is what these guides are for — three jobs in particular:
The 8 guides divide three ways:
Every language is covered by one entry, which works out what the app is built on and installs for that.
These guides assume a Sentry project is there, or soon will be: the setup guides finish by proving that something arrived, and the guides that act on errors read them out of a project you own.
So two things must be in place before anything is reported:
Every guide lives in this one repository, and yet the plugin for any single assistant is not this repository. A build step turns the material into one plugin per tool it supports:
Each of those is generated and kept in its own repository, so what lands in an assistant is built out of this material rather than being it.
Where to start when nothing is reporting yet. One entry looks at what is already in place and, for a new project, goes end to end: creates the project in Sentry, adds the SDK and checks that real data arrives. The other detects the platform and switches on whatever comes next, from tracing and logs to session replay, scheduled-job check-ins and AI monitoring.
For when errors already arrive and the question is what to add next: a shared OpenTelemetry pipeline branched off into Sentry, and pictures of an Apple app's screens taken on every pull request. Two more make the data easier to act on: the source maps and debug files that turn a garbled stack trace back into the source you wrote, and release tags that show which version and which commit brought a problem in.
Everything that comes after a release. One entry starts from an error already sitting in Sentry, pulls its full history and changes the code behind it, then closes it with the commit that fixes it. The other settles which interruptions are worth making and who gets them.
/sentry:seerAsk a question about what Sentry is seeing right now — which errors are turning up most, which ones are hitting the most people — and get the answer in words instead of going and reading a dashboard.
Neither of these two touches your own code. They write and repair the guides themselves: hand one a platform, or a guide that has fallen behind, and it works out the research for itself. A skill carries out a job you have already named; these take the job of keeping the collection true.
Starts from nothing for a platform that has no guide yet: reads Sentry's documentation for it, clones that SDK's source to confirm the options it is about to write down really exist, and opens a pull request with the finished guide and its reference pages.
For a guide that has drifted from the SDK it describes: it finds what changed in the SDK, confirms the new names in that project's own code, and rewrites only the parts that no longer hold.
The plugin wires this up while it installs; nothing else has to be connected.
The first time it is used, it asks you to sign in to Sentry.
search errors
analyse performance
triage issues
read Sentry's documentation
manage projects
Every tool the server offers is listed on its own page:Sentry MCP server
https://mcp.sentry.dev/mcp?utm_source=pluginINSTALL
npx @sentry/agent-plugin install