← All guides

MCPSetup

Sentry MCP with Claude Code: Setup and Your First 5 Queries

By Neo Zino - builder of ClockedCode·Updated August 7, 2026·9 min read

Connect Sentry MCP to Claude Code with one command, sign in with OAuth, confirm it works, then run 5 copy-paste queries mapped to Sentry's real tool names.

Made with DispatchSEO

Run claude mcp add --transport http sentry https://mcp.sentry.dev/mcp, sign in through the browser prompt it triggers, and Claude Code can read a real Sentry issue - stack trace, breadcrumbs, affected users - in the same conversation where you ask about it. That one line is the easy part. What page 1 for this topic doesn't spell out is what happens right after: confirming the sign-in actually worked, which of Sentry's 53 tools your first prompts should reach for, and when the self-hosted path changes the whole setup.

TL;DR: claude mcp add --transport http sentry https://mcp.sentry.dev/mcp connects the hosted server; Claude Code marks it "needs authentication" until you run /mcp and sign in through the browser. Confirm with claude mcp list. Self-hosted Sentry uses a different, token-based path: npx @sentry/mcp-server@latest --access-token=<token> --host=<your-host>. Sentry MCP exposes 53 tools across issues, traces, releases, alerts, and admin - this guide maps 5 starter prompts to the exact ones they call.

The command, and the two ways to run it

Sentry ships Sentry MCP as a hosted remote server at mcp.sentry.dev - the same one claude mcp add --help uses as its own worked example, which tells you how standard this pairing already is:

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

That writes the server at the default local scope, private to you and this project. If Sentry is a daily tool rather than a one-off, add -s user instead so it's available in every project without re-adding it - the same scope flags any MCP server in Claude Code uses.

The remote server isn't the only path. Sentry MCP also ships a stdio transport, meant for self-hosted Sentry installs the hosted server can't reach:

Unless you're running Sentry yourself, the remote server is the right default - it's also the one this guide walks through end to end. The MCP config generator builds this exact command (and a dozen others) if you'd rather pick Sentry from a list than type it by hand.

Confirming Sentry actually answered

Adding the server only writes the config - it doesn't mean Sentry is reachable yet. I tested this exact sequence for this guide, on Claude Code 2.1.223: claude mcp add --transport http sentry https://mcp.sentry.dev/mcp printed Added HTTP MCP server sentry with URL: https://mcp.sentry.dev/mcp to local config, which only confirms the write. claude mcp list is the command that actually checks the connection, and it came back sentry: https://mcp.sentry.dev/mcp (HTTP) - ! Needs authentication - Sentry MCP always starts here, because the hosted server authenticates with OAuth rather than a key you supply up front. Inside a session, run /mcp, pick sentry, and approve the sign-in in the browser tab that opens; from a plain shell, claude mcp login sentry does the same thing without starting a session. Run claude mcp list (or claude mcp get sentry) again afterward and the status flips to connected.

Your first 5 queries

The prompts above aren't generic "ask Claude about Sentry" suggestions - each one maps to a specific tool Sentry MCP exposes, pulled straight from the server's own source rather than guessed at. A few notes on using them for real:

• Errors and issues are the tools you'll reach for most: search_issues returns a list ranked by whatever you ask for (event count, first seen, assignee), and get_event_stacktrace pulls the actual trace instead of you copying one out of the dashboard.
• analyze_issue_with_seer runs Sentry's own root-cause analysis and hands Claude a starting theory instead of a raw stack trace - worth trying before you dig in by hand, not instead of reading the result critically.
• Performance and traces split across two different tools depending on what you're asking: search_events for counts and statistics ("how many 500s in the last hour"), get_trace_details for one specific request's full path through your system.
• Every query needs a project (and usually an org) in scope. If you only have one Sentry project, Claude infers it after the first call; with several, name the project slug in your prompt the first time so it doesn't guess wrong.

What's behind those 5 queries

Sentry's own documentation describes the MCP server only as exposing "Sentry MCP tools" without listing them - I went to the source (packages/mcp-core/src/toolDefinitions.json in getsentry/sentry-mcp) to count what's actually there. 53 tools, and the 5 queries above only touch about a dozen. The rest is worth knowing exists even if you don't reach for it on day one: create_uptime_monitor and find_alert_rules let Claude set up monitoring, not just read it; find_dsns and create_dsn cover onboarding a new service into an existing Sentry project without leaving the terminal; search_docs and get_doc let Claude pull Sentry's own instrumentation docs mid-conversation when it needs to explain how to add the SDK to a new service. None of this is a reason to memorize the list - search_sentry_tools exists specifically so Claude can look up the right one itself - but knowing the categories exist changes what you think to ask for.

Scoping it down

Every connected MCP server sends its tool list into Claude Code's context on every turn it's active, and Sentry's 53 is a heavier one than most - if that's a concern, the remote server accepts a ?skills= query param to narrow what's exposed: https://mcp.sentry.dev/mcp?skills=inspect,triage loads only the debugging-focused subset instead of admin and alerting tools you may never touch from Claude. The ?disable-skills=seer variant does the opposite, dropping one group while keeping the rest.

Access control itself lives outside Claude Code entirely. For the OAuth-connected remote server, what Claude can see is whatever you approved on Sentry's own consent screen when you signed in - you can restrict that to specific projects there, and revisit it any time in Sentry's connected-apps settings. For the stdio transport on self-hosted Sentry, scope is set on the user auth token you generate: Sentry's docs list org:read, project:read, project:write, team:read, team:write, and event:write as what the server needs, and a token minted with fewer scopes limits every tool call regardless of what gets asked of it.

When Sentry MCP isn't the right call

If your team already triages through Sentry's own alerting and dashboards and rarely debugs inside a Claude Code session, connecting Sentry MCP mostly just adds 53 tools' worth of context to every message without a matching payoff - the broader cost of that tradeoff is worth reading before connecting a server you'll use occasionally. And if you're self-hosting Sentry without an OpenAI, Anthropic, or OpenRouter key configured on the server side, the AI-powered search tools (search_events, search_issues's natural-language matching) won't be available - the rest of the toolset still works, but plan prompts around structured queries rather than natural language until that's set up.

FAQ

What's the exact command to connect Sentry MCP to Claude Code?

claude mcp add --transport http sentry https://mcp.sentry.dev/mcp connects the hosted remote server over OAuth - it's the same example Claude Code's own claude mcp add --help text ships. For a self-hosted Sentry instance, run the stdio server instead: npx @sentry/mcp-server@latest --access-token=<token> --host=<your-sentry-host>.

Does Sentry MCP need an API key, or does it use OAuth?

The hosted remote server uses OAuth - Claude Code flags it as needing authentication the moment you add it, and running /mcp inside a session (or claude mcp login sentry from a shell) opens the sign-in flow. The stdio transport, used for self-hosted Sentry, skips OAuth entirely and takes a Sentry user auth token instead via --access-token.

How many tools does Sentry MCP actually expose?

53, as of the version in Sentry's own toolDefinitions.json source. Everything from search_issues and get_issue_details to less obvious ones like analyze_issue_with_seer, create_uptime_monitor, and whoami. Claude Code loads the full list into context on connect - the first 5 queries in this guide only touch about a dozen of them.

Can I limit Sentry MCP to one project or make it read-only?

For the remote OAuth server, scope comes from what you approve on Sentry's consent screen when you sign in, including which projects it can see. For the stdio transport on self-hosted Sentry, scope is set on the user auth token itself - Sentry's docs list org:read, project:read, project:write, team:read, team:write, and event:write as what the server needs, and a token with narrower scopes limits what tools can do regardless of what Claude asks for.

Should I use the remote server or the stdio transport?

Use the remote HTTP server (the one-line command above) unless you're running self-hosted Sentry - it needs no local process and is what Sentry's own docs point new users to. Reach for the stdio transport (npx @sentry/mcp-server@latest) only when you're pointing at a self-hosted instance the hosted server can't reach.

One sign-in, then it's just a conversation

Everything past the sign-in step is Claude reading what Sentry already has, instead of you opening a dashboard tab and copying a stack trace into the prompt by hand. Picking Sentry MCP in the first place is the smaller decision; the six connectors worth running alongside it is where ClockedCode's own vetted list, and the tuned CLAUDE.md that ships with it, saves the rest of the setup work.