What the agent does
No repository is attached. Sentry is an MCP connection: POST /me/connections with type mcp, name sentry, url https://mcp.sentry.dev/mcp and auth mode oauth. All connections use OAuth; the first one opens authorize_url, which the key's creator finishes while signed in to the Rush console. You can point the URL at one organization or one project, https://mcp.sentry.dev/mcp/{organizationSlug} or with a project slug after it. Scoped that way, the tools default to that project and hide discovery tools. The session names the connection. A key run receives only the connections it names, and a grant that is not finished is 422 CONNECTION_NOT_READY.
The agent uses the read tools the server documents for finding issues: search_issues and search_errors, plus the events and traces the catalog says the connection can query. It identifies the latest release and the one before it from those issue and event records, then reads crash-free sessions and crash-free users for each, the error count per hour since the new release, the issues that are new on the new release, and the issues that regressed. Seer is a separate skill on the same server for root cause; this job asks for the comparison, not a Seer investigation, unless an issue's title is not enough to rank it.
release-health.md has the numbers the connection returned, not a narrative in place of them. A table for the two releases: crash-free sessions, crash-free users, and errors per hour since the new release went out. Then new issues ordered by users affected, then regressed issues the same way. The last section is a verdict of healthy, watch or roll back, with the reason tied to one of those figures (a drop in crash-free sessions, a new issue with many users, a regression of an issue that was resolved). If a figure is absent from the connection, the line says so. The agent does not resolve an issue, assign one, or change a release.
The prompt is read only. The Sentry server can update issues; this run does not. Self-hosted Sentry is not this URL. The README for the server says Seer is left out when the host is not sentry.io, and a self-hosted install uses a different transport. This page is the hosted server at mcp.sentry.dev.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Use the Sentry connection. With search_issues and search_errors, compare the latest release with the one before it: crash-free sessions and users, error count per hour since the release, new issues and regressed issues. Write release-health.md with those numbers, the new issues ordered by users affected, and a verdict of healthy, watch or roll back with the reason tied to one of those figures. If a figure is missing, say so. Read only. Do not resolve, assign or ignore any issue."
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
release-health.md is an artifact on the session: name, mime type, and a url on api.prix.dev that downloads the file without a key until url_expires_at. Read the session again for a fresh url. With the key, GET /o/{org}/sessions/{id}/artifacts/release-health.md returns the same file. The live event stream is GET /o/{org}/sessions/{id}/events; a finished run sends status and done.
The file is the comparison a rollback decision needs. Two releases, the crash-free rates, the hourly error counts since the new release, new issues by users affected, regressed issues, and one verdict with its reason. The verdict is a label over those numbers. It is not a claim that a deploy was reverted, and it is not a count of issues the agent did not read.
Someone who can roll back reads the verdict's reason against the table. A watch that cites one new issue should name that issue and the user count the connection returned. A healthy verdict should show crash-free rates that did not fall and an empty or small new-issue list. The transcript keeps the search calls, so a reviewer can see which release identifiers the connection used.
Run it on every deploy
When your deploy pipeline finishes, it POSTs this body to https://api.prix.dev/o/{org}/sessions. Put the release version in the Idempotency-Key so a retried pipeline notification returns the same run. A new deploy needs a new key; a completed run keeps the key it started with. resources stays off unless you also want a repository cloned, which this job does not.
An admin session sets webhook_url on the key. Rush POSTs run.completed, run.failed or run.cancelled to that https URL when the turn finishes, within about 30 seconds. Check webhook-signature against the raw body with the whsec_ secret, or use a Standard Webhooks library. data.result is the answer up to 16 KiB. The markdown file is the artifact, fetched from the session if the verdict text was truncated.
The use case this job follows, with its automation and trigger: Produce a report or file, no repo.
Why run it on Rush?
After a deploy the useful question is whether this release is worse than the last one, and the answer is in crash-free rate, new issues and regressions. Reading those in the Sentry UI is a few screens and a window someone has to remember to open. The agent queries the Sentry connection from a sandbox and writes the comparison down, with the tool results kept on the session, so the verdict points at a figure you can open.
Several services ship on the same afternoon. Each project is its own session, scoped by the connection URL that includes the project slug, and each writes its own release-health.md. The key stops at max_concurrent (4 by default) and answers 429 after that, so the pipeline queues. A follow-up on a parked session, which stays for 7 idle days and costs nothing while parked, can ask for one new issue to be expanded without starting the comparison over.
Frequently asked questions
Will it resolve issues or mark a release as healthy inside Sentry?
No. The prompt is read only and forbids resolve, assign and ignore. The verdict lives in release-health.md. Sentry's issue state is unchanged. A person decides whether to roll back.
Can I pin it to one project?
Yes. Set the connection URL to https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}. Sentry's docs say a scoped server defaults tools to that project and hides discovery tools. An unscoped URL can see every project the OAuth grant allows, which is a wider report than one deploy.
What if the project has no previous release?
The report says there is no earlier release to compare, lists the new issues on the latest release, and does not invent a crash-free delta. The verdict then cannot be a regression against a baseline that does not exist, and the file says that.
Does this include Seer root-cause writeups?
Seer is a skill on the hosted server, and the catalog says the connection can use it to investigate bugs. This prompt asks for the release comparison. Add a sentence to input if you want Seer on the top new issue. Self-hosted Sentry does not include Seer unless you opt in, and it is not the mcp.sentry.dev URL.