sentry MCP

The Sentry MCP server gives a coding agent read access to your Sentry errors, issues and traces so it can debug with real data. Sentry hosts it at https://mcp.sentry.dev/mcp, signs you in with OAuth, and lets you scope the URL to one organization or project. In Claude Code: claude mcp add --transport http sentry https://mcp.sentry.dev/mcp. We checked Sentry's docs and repo on 31 October 2026.

Quick facts

On the licence: FSL is a source-available licence with a delayed switch to Apache 2.0. It lets you read and use the code but restricts competing uses for a period. If you plan to build a product on the server's code, read the licence. For using the hosted server as a customer, it does not matter.

What it lets an agent do

Sentry's docs say the server connects AI assistants to Sentry for searching errors, analysing performance, triaging issues, reading documentation and managing projects. The README is explicit that it is designed for human-in-the-loop coding agents. Tool selection is about developer workflows and debugging, not general-purpose coverage of every Sentry feature.

What that means in practice:

• Find the issue behind an alert and read its stack trace, events and breadcrumbs.
• Search errors, traces and logs by describing what you want in natural language. The README names search_errors, search_traces, search_logs and search_issues as AI-powered search tools that translate your request into Sentry's query syntax.
• Triage, through a triage skill the README names. Check the tool list on your connection to see exactly which actions it offers before you rely on them.
• Use Seer, Sentry's AI debugging, through a seer skill on sentry.io.
• Read Sentry documentation from inside the agent.
• Manage projects, as the docs describe.

The server groups its tools into skills: the README mentions inspect, triage, seer and project-management. You can limit what the agent sees with a query parameter such as ?skills=inspect,triage or ?disable-skills=seer. That is how you build a read-only variant.

The README adds that the project is based on Cloudflare's work towards remote MCP servers.

Install it in each agent

Claude Code

Sentry's docs give the HTTP form with a project scope:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}

Replace the slugs with yours. Then sign in with /mcp or claude mcp login sentry. Sentry's docs recommend scoping to a project when possible: when scoped, tools default to the constrained org and project, and unnecessary discovery tools are hidden.

Sentry also publishes a Claude Code plugin from the repo's own marketplace, which provides a sentry-mcp subagent that Claude delegates to when you ask about Sentry errors, issues, traces or performance:

claude plugin marketplace add getsentry/sentry-mcp
claude plugin install sentry-mcp@sentry-mcp

An experimental variant, sentry-mcp@sentry-mcp-experimental, carries forward-looking tool variants. Try it only if you want to.

Cursor

Use the install button in Sentry's docs, or add this to mcp.json:

{
  "mcpServers": {
    "sentry": {
      "url": "https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}"
    }
  }
}

VS Code

Command Palette, MCP: Add Server, choose HTTP, and enter the endpoint. In VS Code's servers format that is:

{
  "servers": {
    "sentry": {
      "type": "http",
      "url": "https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}"
    }
  }
}

Codex

Sentry's docs say any MCP-compatible client can connect using the HTTP transport at the endpoint URL. For Codex, in ~/.codex/config.toml:

[mcp_servers.sentry]
url = "https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}"

Then run codex mcp login sentry for OAuth. This is our adaptation of Sentry's generic instruction and Codex's documented remote format.

Gemini CLI

Same generic instruction. In ~/.gemini/settings.json:

{
  "mcpServers": {
    "sentry": {
      "httpUrl": "https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}"
    }
  }
}

Authenticate with /mcp auth sentry inside Gemini CLI. Our adaptation.

Compatibility at a glance

Auth and permissions

Hosted server. All connections use OAuth, and the first connection triggers a sign-in to your Sentry account. The agent can do what your Sentry role allows on the orgs and projects you authorise. OAuth tokens are the Bearer kind.

Explicit token. If your client cannot do OAuth, the README describes a direct remote option with a Sentry token in a Sentry-Bearer header. It is intentionally separate from Bearer, which the README says is reserved for MCP OAuth access tokens. With Sentry-Bearer the worker does not store the token, and the client or upstream provider remains responsible for lifetime and refresh. Direct remote auth defaults to all active skills, so narrow them with ?skills= or ?disable-skills=.

Stdio server. Create a user auth token in Sentry. The README lists the scopes needed as of writing: org:read, project:read, project:write, team:read, team:write and event:write. Note the write scopes. If you want read-only, restrict the skills or create a token with fewer scopes and see which tools still work.

npx @sentry/mcp-server@latest --access-token=sentry-user-token

For self-hosted Sentry add --host=sentry.example.com, and --insecure-http for internal plain-HTTP deployments. Seer is not part of self-hosted Sentry, so the seer skill is left out when --host points at a non-sentry.io host; opt back in with --skills=inspect,seer if your deployment runs it.

LLM key for search tools. When you run the stdio server yourself, the AI-powered search tools need an LLM provider: OpenAI, Azure OpenAI, Anthropic or OpenRouter. Set EMBEDDED_AGENT_PROVIDER explicitly; the README says auto-detection from keys is deprecated. Without a provider, those tools are unavailable. On the hosted server this is Sentry's job, not yours.

Skills and scopes cheat sheet

The README gives you three ways to shape what the agent can do, and they stack.

Our default for a first week: a project-scoped URL, ?skills=inspect, and nothing else. Move to triage when you have seen what the agent does with read access.

Real tasks with copy-ready prompts

Triage after a deploy

Look at new unresolved issues in project web-app since the last
release. Group them by likely cause and tell me which one affects the
most users. Do not change any issue.

Debug one issue

Open Sentry issue WEB-APP-4F2. Read the stack trace and breadcrumbs,
find the matching code in this repo and explain the cause. Suggest a
fix as a diff, do not apply it.

Check a performance regression

Search traces for the slowest transactions on /api/orders in the last
24 hours and show the slowest spans.

Close the loop

Find the Sentry issue for the TypeError in checkout, write a fix and a
regression test, and tell me the issue ID to resolve once it ships.

Pair this with GitHub MCP to take a fix to a pull request, and with Datadog MCP if logs live there.

Rate limits

Tool calls are subject to the Sentry API's rate limits. The server retries rate-limited requests, and transient Sentry server errors on reads, after a short wait. When a limit lasts longer, the tool returns a Rate Limited message that says when to try again. The README notes that agents hit per-second limits most often by running many Sentry calls in parallel, so run them one at a time if you see that message.

From an alert to a verified fix

Sentry is the server where the loop from "something broke" to "it is fixed" is shortest, and each step has a place where the agent can go wrong. This is the routine we would follow, with the checks that keep it honest.

Step 3 is where mistakes begin. A stack trace shows the code that was deployed, which may differ from your branch, so ask the agent to confirm the release or commit named in the event before it edits anything. Step 5 is the one models skip, and the one that makes the result checkable. Without a failing test, "fixed" means "the agent believes it".

A prompt that enforces the routine:

Read Sentry issue <id>. Quote the release, the first-seen time and the top
five stack frames. Check that this repository at that release matches those
frames. Then explain the cause, write a test that fails for that reason, and
only then propose a fix. Do not change anything in Sentry.

Telling a real fix from a quiet one

An error that disappears from Sentry has not necessarily been fixed. Three patterns fool people:

• The error moved. A wrapper that catches the exception turns a crash into a silent failure. The Sentry issue disappears and the user still gets nothing. Ask the agent what the user sees after the fix.
• The error is filtered. An ignore rule or a sampling change can hide an issue without touching the cause. Check that no rule changed in the same release.
• The release did not ship. An issue seems to stop because traffic has not reached the new version yet. Compare event counts on the new release against the old one, over a long enough window.

Ask for a before and after: the number of events per hour on the old release and on the new one, with the query used. That is evidence a reviewer can check.

Privacy: what leaves with a stack trace

The security notes say event data can hold personal data. Sentry has controls for that at ingest, and an agent reads whatever those controls let through. Check three things before you give a team access:

1. Scrubbing rules. Does your Sentry project remove emails, tokens and IP addresses before storage? Whatever is stored is what the agent can read.
2. What your SDK sends. Request bodies, cookies and user context are options in the SDK configuration. Tighten them at the source.
3. The model provider. The agent's client sends event text to its model provider. If that is not allowed for production errors, use a model you host, or limit the agent to staging projects.

A project-scoped URL gives you a clean way to enforce this: connect the agent to the staging project only, and keep production behind a person. The scoped endpoints exist for that purpose.

A sensible rollout

1. Week 1. A project-scoped URL for one staging project, ?skills=inspect only, used by one person.
2. Week 2. Add triage for the same project once you have seen what read access produces, and keep the tokens read-limited.
3. Week 3. Connect one production project to a small group, with a note of what data it holds.
4. Week 4. Review which questions were asked and which answers were wrong, and write the useful prompts into a team page.
5. Ongoing. Re-check scopes when Sentry changes them, and remove the access of anyone who has moved teams.

Pair it with GitHub MCP when you want the path from issue to pull request in one session, and keep a person between the two. See also the best MCP servers for where Sentry sits in a typical setup.

Security notes

• Error data can contain personal data. Stack traces, breadcrumbs and event payloads can include user identifiers and request content. They go to your model provider. Check your policy.
• Prompt injection. Error messages and user-supplied fields are text the model reads. A crafted value could contain instructions. Keep the agent in a read-only skill set and review any action it proposes.
• Write tools may exist. The project-management skill and the stdio token scopes (which include write scopes) suggest the server can change state in Sentry. Disable the skills you do not need.
• Scope the URL. Project-scoped endpoints limit what the agent can see.
• Old tutorials. The early reference Sentry server in the MCP project's archive is not the same thing and is no longer maintained. Use Sentry's own.

Limits and known issues

• Debugging-focused. By design it does not expose every Sentry feature.
• Stdio is a work in progress, per the README, and best suited to self-hosted installs.
• LLM dependence for search when you self-run.
• Licence. FSL is source-available, not OSI open source.
• Rate limits hit hardest with parallel calls.
• Repo rename. getsentry/sentry-mcp redirects to getsentry/toolkit ("Agentic tooling for Sentry"). Links and issues may be under the new name.
• Experimental variants are behind ?experimental=1 or the experimental plugin, and can change.

Alternatives

Our take

We read Sentry's docs and the README; we did not connect an account.

The hosted-first design is right for this job. You get OAuth, org and project scoping in the URL, and no local process. The scoping is the feature to use: a project-scoped endpoint makes the agent look at the thing you are fixing and nothing else.

Two cautions. The licence is FSL, so call it source-available. And the data is error data, which tends to include personal information, so decide on purpose what your model provider is allowed to see.

For most teams the best setup is the project-scoped URL plus a read-oriented skill set, used from the coding agent where the fix will happen. Add the write skills later, if you want the agent to update issues.

Setup checklist

1. Find your organization and project slugs in Sentry.
2. Add the server with the project-scoped URL.
3. Sign in with OAuth.
4. Ask for the latest unresolved issue and check it matches your project.
5. Restrict to ?skills=inspect if you want read-only.
6. Try the debug-one-issue prompt on a real error.
7. Review how your provider handles the error data.

Frequently asked questions

What is the Sentry MCP server URL? https://mcp.sentry.dev/mcp, scopable by organization and project.

How do I add it to Claude Code? claude mcp add --transport http sentry <url>.

Is it open source? Source-available under FSL-1.1-Apache-2.0.

Does it work with self-hosted Sentry? Yes, through stdio with --host.

Why do some search tools need an LLM key? They translate natural language into Sentry queries when you self-run.

*Product names are used descriptively. We are not affiliated with Sentry.*