sentry-mcp: Sentry's Remote MCP Server for Coding Agents

The gap sentry-mcp fills between an editor and Sentry

A coding agent working on a bug has no native way to ask Sentry what broke. The agent can read the repository, run tests and inspect logs, but the error data lives behind the Sentry API, and wiring that API into every assistant is repetitive work. sentry-mcp is Sentry's own answer to that: a remote MCP server that acts as middleware to the upstream Sentry API, exposing Sentry data as tools an MCP-capable client can call. The README describes the target audience directly, saying the service is "primarily designed for human-in-the-loop coding agents" and that tool selection is focused on developer workflows and debugging rather than general-purpose Sentry functionality. That sentence is the most important one in the repository. It tells you the maintainers made deliberate omissions. If your need is bulk issue export, alert rule management or org administration, this is not the surface for it. If your need is an assistant that can look up an issue, a trace or an event while you are already in the middle of a debugging session, that is the case the tool was shaped around.

Middleware architecture: Cloudflare transport plus an upstream token

The deployed service runs as a remote MCP server, and the README credits Cloudflare's work on remote MCPs as the basis. The architecture is a proxy: the MCP client speaks to the worker, and the worker makes Sentry API calls on the client's behalf. Authentication has two distinct paths, and the README is careful about the distinction. OAuth-backed sessions use the standard Bearer scheme. Remote clients that can send custom headers can instead pass a Sentry token under the header name Sentry-Bearer. The README states that 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 sessions, and the client or upstream provider stays responsible for token lifetime and refresh. That is a real design decision with a real consequence: fewer moving parts on the server, but rotation and expiry are your problem, and a stale token will surface as failed tool calls rather than a clean re-auth prompt. A second architectural layer is the skills system. Skills are the named groups of tools the server exposes, and they can be narrowed at connection time with query parameters. The README gives ?skills=inspect,triage to expose a subset and ?disable-skills=seer to remove one. The same two knobs exist as CLI flags and environment variables for the stdio path, which keeps the remote and local configurations conceptually aligned.

Running it: plugin install, stdio transport and the flags that matter

There are three ways in. The fastest for Claude Code users is the plugin marketplace. The README gives two commands: claude plugin marketplace add getsentry/sentry-mcp followed by claude plugin install sentry-mcp@sentry-mcp. That installs a sentry-mcp subagent which Claude delegates to when you ask about Sentry errors, issues, traces or performance. A second marketplace entry, sentry-mcp@sentry-mcp-experimental, carries forward-looking tool variants. The third path is the stdio transport, which the README labels a work in progress but describes as the easiest way to run the MCP against a self-hosted Sentry install. The launch command is npx @sentry/mcp-server@latest --access-token=sentry-user-token. For self-hosted deployments you add --host with a hostname only, for example --host=sentry.example.com, and for internal deployments that expose plain HTTP you also add --insecure-http. Unsupported features can be suppressed with --disable-skills=seer. The token itself needs scopes, and the README lists them as org:read, project:read, project:write, team:read, team:write and event:write. Note that project:write and team:write are in that set. The server is not read-only against your Sentry organization, so the token you mint should be scoped to what the agent genuinely needs. The README also gives a JSON block for clients that launch the server as a subprocess, using command npx with args ["@sentry/mcp-server"] and an env object carrying SENTRY_ACCESS_TOKEN, EMBEDDED_AGENT_PROVIDER and the matching provider key.

The LLM provider requirement that silently disables search

The AI-powered search tools, named in the README as search_events and search_issues among others, do not work without an LLM provider. They translate natural language into Sentry's query syntax, so the provider is doing query generation, not retrieval. Supported providers are OpenAI, Azure OpenAI, Anthropic and OpenRouter. Without a configured provider those specific tools are unavailable while every other tool continues to function. This is a quiet failure mode worth planning around. An agent that has been told to search events will simply not have the tool, and depending on the client it may report a missing capability rather than an auth or config error. Configuration uses EMBEDDED_AGENT_PROVIDER set to one of openai, azure-openai, anthropic or openrouter, plus the corresponding API key variable. The README states that EMBEDDED_AGENT_PROVIDER is required when multiple provider keys are set, and that auto-detection based on API keys alone is deprecated and will be removed in a future release. Treat the explicit setting as mandatory today even if a single key is present, because the fallback is on a removal path. OpenRouter additionally accepts OPENROUTER_MODEL, defaulting to openai/gpt-5.6-luna, and OPENROUTER_REASONING_EFFORT, defaulting to high. Those defaults are worth reviewing: a reasoning effort default of high against a search tool that runs on every query is a cost and latency decision the README has already made for you.

Self-hosted Sentry is supported, with Seer as the sharp edge

Self-hosted support is real but partial. The README warns that some features, Seer among them, may not be available on self-hosted instances, and that you can disable specific skills to prevent unsupported tools from being exposed. The flag is --disable-skills=seer on the CLI, MCP_DISABLE_SKILLS in the environment, or ?disable-skills=seer on the remote URL. If you skip that step on an instance without Seer, the tools are still advertised and the failure arrives at call time instead of at connect time. The host handling has its own sharp edge. The README says to pass a hostname only with --host, and that leaving the host variable unset targets Sentry SaaS automatically. That means a typo or an empty SENTRY_HOST does not fail loudly, it silently points the agent at sentry.io with your self-hosted token. For internal deployments without TLS, --insecure-http exists, and the README's example uses --host=sentry.internal:9000. Sending a Sentry token in cleartext over a network you do not fully control is a decision to make deliberately, not a default to inherit. The README does not describe a certificate-pinning option or a proxy setting for the stdio transport, so if your environment requires either, plan on testing it before you depend on it.

How sentry-mcp differs from the Sentry CLI and SDK integrations

The obvious alternative is the Sentry CLI plus the Sentry SDKs already wired into your application. Those solve a different problem. The CLI is a command-line tool you invoke yourself, and the SDKs instrument your code so events reach Sentry in the first place. Neither exposes Sentry data as callable tools inside an agent's reasoning loop. sentry-mcp's distinguishing move is that it hands the agent the query surface and lets the model decide what to fetch mid-task, which is exactly why the maintainers scoped it to human-in-the-loop workflows rather than full API coverage. The trade-off is that you are granting a model write-capable scopes and an LLM provider key, and you are accepting that the tool list is curated by Sentry rather than generated from the API. A second comparison point is the MCP Inspector, which the README covers as a way to test the service with pnpm inspector, connecting to http://localhost:5173 and triggering the authentication flow. The README notes that OAuth issues on 127.0.0.1 can sometimes be resolved by using localhost instead, at http://localhost:6274. That is a debugging aid rather than an alternative, but it is the practical way to see which tools a given skills configuration actually exposes before pointing an agent at it.

Contributing, releases and what the licence field does not tell you

Local development starts with make setup-env, which the README says creates .env files and installs shared agent skills, and which also runs npx @sentry/dotagents install to pull skills from getsentry/skills into .agents/skills/, symlinked into .claude/skills and .cursor/skills. Running the MCP locally against Sentry's own service requires an OAuth app created under Settings, API, Applications, with homepage URL http://localhost:5173 and authorized redirect URI http://localhost:5173/oauth/callback, plus a client ID and secret written into .env. That is a non-trivial setup path, and it is the cost of contributing rather than of using the hosted endpoint. On maintenance, the release cadence visible in the repository metadata shows 0.37.0 in early July 2026, then 0.38.0 and 0.39.0 in late August 2026. Pre-1.0 versioning with occasional multi-week gaps between releases is what you should expect, and the README's own notes about the stdio transport being a work in progress and about provider auto-detection being deprecated both point to active churn. The licence field is reported as NOASSERTION, which means the repository metadata does not map to a standard SPDX identifier. That is a fact about the metadata, not a legal conclusion. If you plan to redistribute the server or embed it in a product, read the actual LICENSE file in the repository and get your own advice rather than inferring terms from the field.

Editorial conclusion

Adopt sentry-mcp if you already run a coding agent against Sentry and want issue, trace and event context pulled in without leaving the editor, and you are willing to supply a Sentry user auth token plus an LLM provider key for the AI search tools. Do not adopt it as a general Sentry automation layer: the README states the tool selection targets developer workflows and debugging, not full API coverage. Before rolling it out, verify that your self-hosted instance supports Seer (otherwise pass --disable-skills=seer), confirm your token carries org:read, project:read, project:write, team:read, team:write and event:write, and decide whether you are using the hosted endpoint at mcp.sentry.dev or the stdio transport via npx @sentry/mcp-server@latest.

Official sources

1. getsentry/sentry-mcp on GitHub
2. Issues
3. Project website
4. README
5. Releases