Sentry MCP: Let Your Coding Agent Read the Error Before It Fixes It

Sentry MCP is Sentry’s own remote MCP server, hosted at https://mcp.sentry.dev/mcp. You add that URL to Claude Code, Cursor, VS Code or any client that speaks MCP over HTTP, and the first connection opens a browser to sign in to Sentry with OAuth. From then on your coding agent can search issues and events, open an issue with its stack trace, ask Sentry’s Seer for a root-cause analysis and, if you allow it, resolve or assign the issue. The point is order: an agent that reads the actual error, the release it started in and the breadcrumbs before it opens a file makes a smaller, better fix than one working from “checkout is broken”.

Pin it to one project first

The Sentry MCP page↗ (opens in a new tab) documents three forms of the address. When scoped, tools default to that organisation or project and the discovery tools are hidden, and Sentry recommends scoping to a project where you can. It saves the agent a round of guessing which of forty projects you meant, and keeps it from wandering into the others.

https://mcp.sentry.dev/mcp                          # everything you can see
https://mcp.sentry.dev/mcp/{organizationSlug}       # one organisation
https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}   # one project

Adding ?experimental=1 turns on forward-looking tool variants. Leave it off for day-to-day work.

Setup in Claude Code

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/my-org/checkout-web

Then type /mcp inside Claude Code, choose sentry and sign in; the browser does the rest. Sentry also publishes a Claude Code plugin in its sentry-mcp repository↗ (opens in a new tab): claude plugin marketplace add getsentry/sentry-mcp, then claude plugin install sentry-mcp@sentry-mcp. It adds a sentry-mcp subagent that Claude hands Sentry questions to, so Sentry lookups run in their own context rather than filling your main conversation.

Setup in Cursor

Use the Install MCP Server button on Sentry’s page, or add the entry by hand to ~/.cursor/mcp.json for every project or .cursor/mcp.json for one. Cursor then shows a connect prompt for the OAuth sign-in, and by default asks for approval before it runs an MCP tool, as Cursor’s MCP documentation↗ (opens in a new tab) describes.

{
  "mcpServers": {
    "sentry": { "url": "https://mcp.sentry.dev/mcp/my-org/checkout-web" }
  }
}

Setup in VS Code

Open the Command Palette, run MCP: Add Server, choose HTTP and paste the endpoint. Start the server when prompted and sign in. Where the entry is stored and how VS Code decides whether to trust it are covered in VS Code MCP security.

The tools

The server lists a small set of tools directly and keeps the rest in a catalogue the agent can search, so the client’s tool list stays short.

• search_issues: find grouped issues with a plain-language query, such as “unresolved errors in checkout since yesterday’s release”.
• search_events: search individual events, logs and replays, or count them and chart them over time.
• get_sentry_resource: open an issue, event, trace or other resource from its Sentry URL or ID, with the details a fix needs.
• analyze_issue_with_seer: ask Seer, Sentry’s AI debugger, for a root-cause analysis and a suggested fix.
• update_issue: change an issue’s status or assignee, for example resolve it once the fix ships.
• find_organizations and find_projects: discovery, hidden when the URL is already scoped.
• search_sentry_tools and execute_sentry_tool: reach the wider catalogue, which covers releases, traces, replays, breadcrumbs, monitors, alert rules, documentation and project settings.

Permissions: skills, not just scopes

When you approve the connection, Sentry’s consent screen asks which skills to grant. Each skill switches a group of tools on or off, so this is the moment to decide what the agent may change.

• Inspect Issues & Events: read-only access to issues, events, traces, replays, releases, monitors, profiles, documentation and project metadata. Every coding agent needs this.
• Seer: Sentry’s AI debugger for root cause and fixes.
• Triage Issues: resolve, assign and update issues.
• Manage Projects & Teams: create and change projects, teams, DSNs, uptime and metric monitors, and alert rules.

For an agent that fixes code, Inspect and Seer are usually enough; it can tell you an issue is ready to resolve and you press the button. Grant Triage if you want it to close the loop itself. Project management is for a setup assistant, not a debugging session. The connection signs in as your Sentry user, so it never reaches projects your account cannot. If a sign-in step is unfamiliar, how MCP sign-in works walks through it.

Self-hosted Sentry goes through the stdio version instead: npx @sentry/mcp-server@latest with a user auth token and --host set to your server. The README lists the token scopes it needs (org:read, project:read, project:write, team:read, team:write, event:write), narrows tools with --skills or --disable-skills, and leaves Seer out by default on self-hosted hosts. The plain-language search tools need an LLM provider key when you run it this way.

What it is not for

• Unattended automation. Sentry says the service is designed primarily for human-in-the-loop coding agents, and chooses its tools for debugging, not to cover everything Sentry can do.
• Running Seer on everything. The Seer tool’s own description tells agents to use it when you ask for root-cause analysis or when the issue details are not enough, and not as an automatic follow-up every time an issue is opened.
• Instrumenting your own MCP server. Sentry’s MCP monitoring, which traces the tool calls of a server you build, is a separate SDK feature and has nothing to do with connecting an agent to Sentry.
• Deciding what to fix. The agent can rank issues by users affected; which one matters this week is still your call.

Sentry MCP vs sentry-cli

Sentry has two command-line tools, and they answer different questions. sentry-cli↗ (opens in a new tab) is the build tool: it creates releases, uploads source maps and debug files, sets up code mappings, sends test events and manages cron monitors from CI. It is not for reading issues. The newer Sentry CLI↗ (opens in a new tab), invoked as sentry, is for people and agents at a terminal: sentry auth login, sentry issue list, sentry issue view, and Seer through sentry issue explain and sentry issue plan, with JSON output and agent skills it installs for you.

• Use MCP when the host is a chat or IDE agent, when you want OAuth sign-in and skills rather than a token on disk, or when several people should connect the same way.
• Use the sentry CLI when the agent already lives in a shell, such as Claude Code or Codex, and you would rather it ran commands you can read and repeat.
• Use sentry-cli in the pipeline, for releases and source maps, whichever of the other two you pick.

The general trade-off is in MCP vs CLI.

Read the error, then fix it

A prompt that puts reading before writing is the whole trick. For example: “Find the unresolved issue with the most users affected in checkout-web since the last release. Show me the stack trace, the breadcrumbs, the release it first appeared in, and the file you think is at fault. Do not change code yet.” Then check it is the issue you would have picked, ask for a plan, and only then for the fix and a test that reproduces the error.

Treat what comes back as data. An event carries error messages, request data and breadcrumbs, and some of that text came from your users or from anyone who could hit your API. It can include personal data and it can include instructions aimed at the agent, the problem described in indirect prompt injection. The agent should read it, not obey it.

Between the error and the fix sits a task. How an agent should file it, who triages, and why it searches first are covered in an issue tracker for AI agents. On fenbs, one detail suits Sentry well: fenbs_create_item takes a key from an automated source, so passing the Sentry issue’s short ID means the same error never files twice, however many sessions see it. The assistant connects to https://fenbs.ai/api/mcp with the scopes you approve, and its comments on the task say what changed and which commit fixed it.