# Using Atlas with Sentry in 2026 > Atlas pulls a Sentry issue's stack trace, breadcrumbs, and release context through the official Sentry MCP server and proposes the fix as a reviewable diff. Atlas pulls a Sentry issue's stack trace, breadcrumbs, and release context through the official Sentry MCP server, maps the offending frame into your working tree, and proposes the fix as a reviewable diff. Add it over stdio with atlas mcp add sentry --env SENTRY_ACCESS_TOKEN=$SENTRY_ACCESS_TOKEN -- npx -y @sentry/mcp-server@latest, or use OAuth against the hosted server at https://mcp.sentry.dev/mcp. ## What the Atlas and Sentry integration does Atlas pulls a Sentry issue's stack trace, breadcrumbs, and release context through the official Sentry MCP server, maps the offending frame into your working tree, and proposes the fix as a reviewable diff. In 2026 the input is a Sentry issue short ID and the output is a patch. Debugging from Sentry usually means three windows: the issue page, the editor, and a terminal. The Sentry MCP server collapses that. Atlas reads the stack trace, the breadcrumbs that led to the exception, and the release context that says which deploy introduced it. Then it does the part a browser cannot: it maps the offending frame onto the real file in your checkout and writes a patch. You are reviewing a diff instead of translating a line number in a minified frame into a place in your repository. ## Adding the Sentry MCP server over stdio Add the Sentry MCP server over stdio with atlas mcp add sentry --env SENTRY_ACCESS_TOKEN=$SENTRY_ACCESS_TOKEN -- npx -y @sentry/mcp-server@latest. The credential is a Sentry user auth token carrying 5 scopes: org:read, project:read, project:write, team:read, and event:write. Mint the token in Sentry before you register the server, and grant exactly the 5 scopes the integration needs. org:read and project:read let Atlas find the issue. team:read resolves ownership. project:write and event:write let Atlas act on the issue rather than only stare at it. Export SENTRY_ACCESS_TOKEN in your shell, pass it through with --env, and the stdio server started by npx -y @sentry/mcp-server@latest picks it up on launch. ## The OAuth alternative: Sentry's hosted MCP server Prefer OAuth over a long-lived token by pointing Atlas at Sentry's hosted server: run atlas mcp add sentry --url https://mcp.sentry.dev/mcp, followed by atlas mcp auth sentry. That path skips minting a Sentry user auth token entirely, which makes it the simpler of the 2 supported setups. Hosted Sentry users generally want the OAuth path. There is no token to store, rotate, or accidentally commit, and the grant is tied to your Sentry account rather than to a secret in an env var. Two commands do it: atlas mcp add sentry --url https://mcp.sentry.dev/mcp registers the hosted server, and atlas mcp auth sentry completes the browser flow. Reach for the stdio server with SENTRY_ACCESS_TOKEN when you need a non-interactive environment or a self-hosted Sentry. ## Pointing Atlas at self-hosted Sentry Self-hosted Sentry needs exactly 1 extra setting: pass --host=sentry.example.com to the stdio server, or set SENTRY_HOST. Everything else in the Atlas integration is unchanged, including the @sentry/mcp-server@latest binary, the SENTRY_ACCESS_TOKEN, and the stack trace to diff workflow. Running your own Sentry does not mean running a different integration. The same official @sentry/mcp-server@latest package speaks to your instance once it knows where to find it, either through --host=sentry.example.com on the command line or through the SENTRY_HOST environment variable. Your Sentry user auth token still needs the org:read, project:read, project:write, team:read, and event:write scopes, minted on your own instance rather than on sentry.io. ## The daily loop: short ID in, patch out Paste a Sentry issue short ID into Atlas and let it read the stack trace, open the offending file, and propose the patch. The short ID is the entire prompt in 2026: Atlas resolves it to the issue's stack trace, breadcrumbs, and release context through the Sentry MCP server. The short ID is the handle a Sentry alert already gives you, which is why it is the right prompt. Atlas expands it into the full issue: the frames, the breadcrumbs that show what the user did before the exception, and the release that shipped the regression. Then it opens the offending file in your working tree and writes a candidate fix. Review that diff on its merits. Atlas proposing a patch is not the same as the patch being right, and the stack trace it quotes is how you check its reasoning. ## The two tools that need an LLM provider key Exactly 2 Sentry MCP tools carry an extra requirement: search_events and search_issues need an LLM provider key configured on the Sentry side. The rest of the Sentry MCP server works without one, so a fresh Atlas install can read a stack trace by short ID immediately. The distinction saves a confusing first hour. If Atlas can open a specific Sentry issue by short ID but cannot run an open ended search across your events, nothing is broken in the Atlas configuration. search_events and search_issues depend on an LLM provider key configured in Sentry itself, and until that exists those two tools will not work. Every other tool on the Sentry MCP server, including the ones that carry the stack trace, breadcrumbs, and release context, works without one. ## Setup 1. Add the Sentry MCP server over stdio with atlas mcp add sentry --env SENTRY_ACCESS_TOKEN=$SENTRY_ACCESS_TOKEN -- npx -y @sentry/mcp-server@latest 2. Mint a Sentry user auth token carrying the org:read, project:read, project:write, team:read, and event:write scopes. 3. Prefer OAuth instead by pointing at the hosted server: atlas mcp add sentry --url https://mcp.sentry.dev/mcp followed by atlas mcp auth sentry. 4. For self-hosted Sentry, pass --host=sentry.example.com to the stdio server, or set SENTRY_HOST. 5. Paste a Sentry issue short ID into Atlas and let it read the stack trace, open the offending file, and propose the patch. 6. Remember that search_events and search_issues need an LLM provider key configured on the Sentry side; the rest work without one. ## FAQ ### how to connect Atlas to Sentry Run atlas mcp add sentry --env SENTRY_ACCESS_TOKEN=$SENTRY_ACCESS_TOKEN -- npx -y @sentry/mcp-server@latest for the stdio server, or atlas mcp add sentry --url https://mcp.sentry.dev/mcp plus atlas mcp auth sentry for OAuth. ### what scopes does the Sentry MCP server token need A Sentry user auth token carrying org:read, project:read, project:write, team:read, and event:write. Pass it as SENTRY_ACCESS_TOKEN when registering the stdio server. ### can Atlas fix a bug straight from a Sentry issue Yes. Paste a Sentry issue short ID and Atlas reads the stack trace, breadcrumbs, and release context, opens the offending file in your working tree, and proposes the patch as a diff. ### how do I use Atlas with self-hosted Sentry Pass --host=sentry.example.com to the stdio Sentry MCP server, or set SENTRY_HOST. The rest of the setup, including the token scopes, is unchanged. ### why do search_events and search_issues fail in the Sentry MCP server search_events and search_issues need an LLM provider key configured on the Sentry side. Every other tool on the Sentry MCP server works without one. ### Sentry MCP OAuth or access token, which should I use Use OAuth against https://mcp.sentry.dev/mcp with atlas mcp auth sentry when you can, since there is no long-lived token to store. Use SENTRY_ACCESS_TOKEN with the stdio server for self-hosted or non-interactive setups. ### does the Sentry MCP server give Atlas breadcrumbs and release context Yes. Atlas pulls a Sentry issue's stack trace, breadcrumbs, and release context through the official Sentry MCP server before proposing a fix. --- Canonical HTML: https://runatlas.sh/resources/integrations/sentry Source of truth: aeo_pages row `/resources/integrations/sentry` (segment: Integrations) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.