Sentry MCP Server

Sentry MCP

Sentry's MCP service is primarily designed for human-in-the-loop coding agents. Our tool selection and priorities are focused on developer workflows and debugging use cases, rather than providing a general-purpose MCP server for all Sentry functionality.

This remote MCP server acts as middleware to the upstream Sentry API, optimized for coding assistants like Cursor, Claude Code, and similar development tools. It's based on Cloudflare's work towards remote MCPs.

Getting Started

You'll find everything you need to know by visiting the deployed service in production:

https://mcp.sentry.dev

If you're looking to contribute, learn how it works, or to run this for self-hosted Sentry, continue below.

Claude Code Plugin

Install as a Claude Code plugin for automatic subagent delegation:

This provides a sentry-mcp subagent that Claude automatically delegates to when you ask about Sentry errors, issues, traces, or performance.

For forward-looking tool variants and features:

Stdio vs Remote

While this repository is focused on acting as an MCP service, we also support a stdio transport. It is the easiest way to run the MCP server against a self-hosted Sentry install.

Note: The AI-powered search tools (search_errors, search_traces, search_logs, search_issues, etc.) require an LLM provider (OpenAI, Azure OpenAI, Anthropic, or OpenRouter). These tools use natural language processing to translate queries into Sentry's query syntax. Without a configured provider, these specific tools will be unavailable, but all other tools will function normally.

Sentry CLI (recommended)

Run the stdio server with the Sentry CLI's sentry mcp command. It uses your CLI login, so the MCP config needs no token:

The CLI also installs with brew install getsentry/tools/sentry,
npm install -g sentry, or irm https://cli.sentry.dev/install.ps1 | iex on
Windows. See the CLI installation guide.

Other clients take the same command:

Pass <org>/ or <org>/<project> to limit every call to one organization or
project (sentry mcp acme/, sentry mcp acme/web), and --experimental for
forward-looking tool variants. Run sentry mcp --help for every flag and
environment variable, or see the sentry mcp docs.
SENTRY_AUTH_TOKEN, when set, wins over the stored login. See
docs/operations/stdio-auth.md.

To use a token, create a User Auth Token in Sentry with the necessary scopes. As of writing this is:

Need to connect to a self-hosted deployment? Log in to it with
sentry auth login --url https://sentry.example.com, then set
SENTRY_HOST (e.g. SENTRY_HOST=sentry.example.com)
in the MCP server's environment, which also scopes
SENTRY_AUTH_TOKEN to that server. For isolated internal
deployments that only expose plain HTTP, use an http://
SENTRY_URL instead. See the
CLI self-hosted guide.

Seer is not part of self-hosted Sentry, so the seer skill is left out of the
default skill set whenever the host is not sentry.io. If your
self-hosted deployment does run Seer, opt back in explicitly:

You can also disable any other skill to prevent unsupported tools from being
exposed:

For self-hosted instances without TLS:

Legacy: npx @sentry/mcp-server

@sentry/mcp-server still
ships the same server, bundled without the rest of the CLI, for clients that
launch it through npx. It shares the CLI's login and takes the same flags and
environment variables:

--access-token / SENTRY_ACCESS_TOKEN from older releases still work but are
deprecated: they act as SENTRY_AUTH_TOKEN and print a warning on stderr.

Remote with an Explicit Sentry Token

Remote clients that support custom HTTP headers can pass an upstream Sentry API
token directly to the Cloudflare transport:

Sentry-Bearer is intentionally separate from Bearer: Bearer is reserved
for MCP OAuth access tokens. With Sentry-Bearer, the worker does not store,
validate, exchange, or refresh the upstream token. It forwards the token through
the same Sentry API calls used by OAuth-backed sessions, and the client or
upstream provider remains responsible for token lifetime and refresh.

Direct remote auth defaults to all active MCP skills. You can narrow the exposed
tools with ?skills=inspect,triage or ?disable-skills=seer.

Environment Variables

Important: Always set EMBEDDED_AGENT_PROVIDER to explicitly specify your LLM provider. Auto-detection based on API keys alone is deprecated and will be removed in a future release. See docs/operations/embedded-agents.md for detailed configuration options.

Example MCP Configuration

If you leave the host variable unset, the CLI automatically targets the Sentry
SaaS service. Only set the override when you operate self-hosted Sentry.

Setting SENTRY_HOST to a self-hosted host also drops the seer skill from
the default set, since Seer is not available on self-hosted Sentry. For a
self-hosted deployment that does run Seer, opt in with MCP_SKILLS:

Rate Limits

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

MCP Inspector

MCP includes an Inspector, to easily test the service:

Enter the MCP server URL (http://localhost:5173) and hit connect. This should trigger the authentication flow for you.

Note: If you have issues with your OAuth flow when accessing the inspector on 127.0.0.1, try using localhost instead by visiting http://localhost:6274.

Local Development

To contribute changes, you'll need to set up your local environment:

1. Set up environment and agent skills:

   make setup-env  # Creates .env files and installs shared agent skills
   

   Copy

   This also runs npx @sentry/dotagents install to install shared skills from getsentry/skills into .agents/skills/ (symlinked into .claude/skills and .cursor/skills). If you need to update skills later, run it directly:

   npx @sentry/dotagents install
   

   Copy

2. Create an OAuth App in Sentry (Settings => API => Applications):

   • Homepage URL: http://localhost:5173
   • Authorized Redirect URIs: http://localhost:5173/oauth/callback
   • Note your Client ID and generate a Client secret

3. Configure your credentials:

   • Edit .env in the root directory and add either OPENAI_API_KEY or OPENROUTER_API_KEY
   • Edit packages/mcp-cloudflare/.env and add:
     • SENTRY_CLIENT_ID=your_development_sentry_client_id
     • SENTRY_CLIENT_SECRET=your_development_sentry_client_secret
     • COOKIE_SECRET=my-super-secret-cookie

4. Start the development server:

   pnpm dev
   

   Copy

Verify

Run the server locally to make it available at http://localhost:5173

To test the local server, enter http://localhost:5173/mcp into Inspector and hit connect. Once you follow the prompts, you'll be able to "List Tools".

Tests

There are three test suites included: unit tests, evaluations, and manual testing.

Unit tests can be run using:

Evaluations require a .env file in the project root with some config:

Note: The root .env file provides defaults for all packages. Individual packages can have their own .env files to override these defaults during development.

Once that's done you can run them using:

Manual testing (preferred for testing MCP changes):

Note: The CLI defaults to http://localhost:5173. Override with --mcp-host or set MCP_URL environment variable.

Comprehensive testing playbooks:

• Stdio testing: See docs/testing/stdio.md for complete guide on building, running, and testing the stdio implementation (IDEs, MCP Inspector)
• Remote testing: See docs/testing/remote.md for complete guide on testing the remote server (OAuth, web UI, CLI client)

Development Notes

Automated Code Review

This repository uses automated code review tools (like Cursor BugBot) to help identify potential issues in pull requests. These tools provide helpful feedback and suggestions, but we do not recommend making these checks required as the accuracy is still evolving and can produce false positives.

The automated reviews should be treated as:

• ✅ Helpful suggestions to consider during code review
• ✅ Starting points for discussion and improvement
• ❌ Not blocking requirements for merging PRs
• ❌ Not replacements for human code review

When addressing automated feedback, focus on the underlying concerns rather than strictly following every suggestion.

Contributor Documentation

Looking to contribute? Start at the Toolkit documentation index
for CLI, MCP, and shared guides. See AGENTS.md for repository rules and
packages/cli/AGENTS.md for CLI-specific rules.