Sentry MCP Server

The Sentry MCP Server implements the Model Context Protocol and gives AI coding agents access to a Sentry account: search errors and issues and view them in detail with the stack trace, query events and distributed traces, narrow down performance anomalies, inspect releases and projects, and search the Sentry documentation. On top of that there is a small set of write actions — such as resolving, reopening, assigning, or muting an issue, and creating projects, teams, and DSNs. In total the server exposes roughly two dozen tools; the focus is explicitly on developer and debugging workflows rather than full Sentry administration.

Hosted option (recommended)

Sentry runs the server as a hosted remote service at https://mcp.sentry.dev/mcp (HTTP transport). The path can optionally be scoped to an organization (/mcp/{organization}) or a project (/mcp/{organization}/{project}). All connections use OAuth: on the first call the client opens a browser window to sign in to the Sentry account and stores the grant for later sessions. The natural-language search tools (search_events, search_issues) work here without your own key because the service provides the required language model itself.

Local option

Alternatively, the source-available package @sentry/mcp-server (version 0.39.0 at the time of review) can be run locally over stdio:

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

The token comes from the Sentry account settings and needs the scopes org:read, project:read, project:write, team:read, team:write, and event:write. For the natural-language search tools you additionally need your own access to a language model provider locally (OpenAI, Azure OpenAI, Anthropic, or OpenRouter). Self-hosted Sentry installations are connected via --host=sentry.example.com (and --insecure-http if needed); some features such as Seer are unavailable there and can be turned off with --disable-skills=seer.

For Claude Code there is also a plugin marketplace:

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

Why the hosted option is preferred

Sentry deliberately built the hosted option so that even the natural-language search tools work without your own language model access: the service runs the required model itself, so users don't need to configure a separate OpenAI or Anthropic key. The local option remains mainly relevant for teams connecting a self-hosted Sentry installation or, for compliance reasons, avoiding routing traffic through an additional third-party service.

Typical use cases

The server is particularly useful for debugging workflows where a coding agent should ask directly about an error report and evaluate its stack trace with context, without anyone manually switching between the IDE and the Sentry UI. It's also helpful for tracking performance regressions after a deployment or automatically summarizing all open critical issues in a project before a release. Given the limited write scope, the server is less suited for fully administering a Sentry account, such as setting up complex alert rules.

A Sentry account with access to the target organization or project. The hosted option only needs an MCP client that supports remote servers over HTTP and OAuth. The local option additionally requires Node.js (npx), a Sentry user token with the right scopes, and — for natural-language search — your own access to a language model provider.

For the hosted option, register the remote server in your MCP client, e.g. in Claude Code with claude mcp add --transport http sentry https://mcp.sentry.dev/mcp, in Cursor via an mcpServers entry with "url": "https://mcp.sentry.dev/mcp", or in VS Code via a servers entry with "type": "http". On the first call the client opens the OAuth dialog; sign in to the Sentry account there and confirm access. The URL can optionally be scoped to an organization or a project.

For the local option, create a token in the Sentry account settings under "User Auth Tokens" with the scopes org:read, project:read, project:write, team:read, team:write, and event:write, and start the server via npx @sentry/mcp-server@latest --access-token=<token>. For natural-language search, additionally set a language model provider's credentials as environment variables. Connect self-hosted Sentry instances via --host=.

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

Hosted option: OAuth sign-in to the Sentry account, triggered from the client; the grant is stored for later sessions. Local option: Sentry user token (--access-token) with the scopes org:read, project:read, project:write, team:read, team:write, event:write; for the HTTP transport alternatively as the header Authorization: Sentry-Bearer <token>.

Effective access matches the signed-in Sentry account or the token scopes and the optional path scoping to an organization or project. Within that scope, mostly read actions are possible (errors, issues, events, traces, releases, projects, documentation). Only a few write actions are provided: changing issue status and assignment, and creating projects, teams, and DSNs.

Requests and tool parameters go to the Sentry API. Responses contain the account's monitoring data — including stack traces, event details, and trace data that, depending on the application, may contain personal data or secrets — and are passed to the MCP client and its language model. With the hosted option, the connection runs through Sentry's own service at mcp.sentry.dev, which uses its own language model for natural-language search. With the local option, the server runs on your own machine but still calls the Sentry API and sends search queries to the configured language model provider.

Stack traces and event data in Sentry can contain plaintext secrets, tokens, or personal data; through the server these enter the context of the agent and its language model. An overly broad token, or signing in with an account that sees many organizations, widens that radius. Limit access with the path scoping to the organization or project actually needed, use a dedicated token with minimal scopes for automated workflows, treat it like a password, and only deliberately allow the write tools (issue status, project/team/DSN creation).