Sentry MCP server security: scope it to a project, keep the write skills off

The short answer

Connect to https://mcp.sentry.dev/mcp/<org>/<project> so the server is scoped to one project, and approve only the default skills at sign-in: Inspect, which is read-only, and Seer. Leave Triage and Manage Projects & Teams off unless the agent truly needs to resolve issues or change alert rules. If you see @modelcontextprotocol/server-sentry in a config, replace it: that reference server was archived in May 2025.

What the server can do

Sentry groups its MCP tools into skills, chosen when you authorize the connection. From the server’s own source:²

The defaults are sensible. The risk comes from the person authorizing the connection ticking every box because the agent asked for “full access” to fix something.

All connections to the hosted server use OAuth.¹ With a token passed directly instead of OAuth, the connection defaults to all active skills, and ?skills= or ?disable-skills= on the URL narrows them.² That difference matters for CI and shared setups: a token-based config can quietly expose the write skills that the OAuth flow leaves off by default.

Scope the URL

The hosted server can be scoped in the URL itself:¹

Sentry recommends scoping to a project when possible; when scoped, tools default to that project and discovery tools are hidden.¹ A project-scoped config for Claude Code looks like this:

Code Data in JSON, the format software uses to pass records and settings.

{
  "mcpServers": {
    "sentry": { "type": "http", "url": "https://mcp.sentry.dev/mcp/acme/web-frontend" }
  }
}

Saved as .mcp.json at the project root, that’s a project-scope server shared with the team through version control.⁵ Everyone who opens the repository gets the same, narrow Sentry connection.

If you need a token instead of OAuth, add the skill list to the URL so the default doesn’t widen it:

Code What the screen or file shows, copied as is.

https://mcp.sentry.dev/mcp/acme/web-frontend?skills=inspect

The self-hosted path needs write scopes

For self-hosted Sentry, the project runs the server over stdio with a user auth token. The README lists the scopes that token needs today: org:read, project:read, project:write, team:read, team:write and event:write.² That’s a token that can change projects and teams, held on the developer’s machine, whatever skills you enable.

You can still narrow the tools with --disable-skills or MCP_DISABLE_SKILLS (for example project-management),² but the credential underneath keeps its write scopes. On self-hosted installs, treat the Sentry token as a write credential and store it like one: an environment variable, never the config file.

Error events are untrusted input

Here’s the part most setups miss. A Sentry event is built from what your users sent you: request paths, form fields, headers, exception messages that echo input. An agent that reads events is reading text written by strangers.

That puts a Sentry connection squarely in Simon Willison’s “lethal trifecta”: private data, exposure to untrusted content, and the ability to communicate externally.⁴ Sentry supplies the first two on its own. The third comes from whatever else is connected: a GitHub server that can open pull requests, a Slack server that can post, or a shell.

Three habits keep that in check:

1. Read-only Sentry plus a human-reviewed fix. Let the agent read the event and propose a patch. A person merges it.
2. Don’t pair Sentry with an outbound tool in the same session unless that tool needs approval for every call.
3. Send less to Sentry. Keep passwords, tokens and personal data out of events where your app reports them, so there’s less for an agent to read in the first place.

The archived reference server

@modelcontextprotocol/server-sentry is one of the reference servers moved to modelcontextprotocol/servers-archived, which was created and archived on 28 May 2025, along with the old GitHub, Slack and Postgres servers.³ It’s unmaintained. Replace it with Sentry’s own server.

What a config scanner will tell you

Not much, for remote servers. In our runs of deedglass 0.13.0’s scan, the Sentry entry, given as a URL, added no write paths to the grade, scoped or not.⁶⁶ The scanner can’t see which skills you approved at sign-in, because that choice lives in Sentry, not in the file. Review Sentry’s connection page for the skills granted, and revoke and reconnect if they’re wider than you want.

A checklist

• The URL names an organization and a project.
• Only Inspect (and Seer, if you use it) were approved at sign-in.
• Token-based configs carry ?skills=inspect.
• No @modelcontextprotocol/server-sentry anywhere.
• Self-hosted tokens live in an environment variable, not the config.
• Sentry isn’t connected in the same session as an unapproved outbound tool.

Questions people ask

Is the Sentry MCP server read-only?

Not necessarily. Its Inspect skill is read-only and on by default, but the Triage and Manage Projects & Teams skills can resolve issues and change projects, teams and alert rules if you grant them.²

How do I limit the Sentry MCP server to one project?

Use https://mcp.sentry.dev/mcp/{organizationSlug}/{projectSlug}. Tools then default to that project and discovery tools are hidden.¹

Can I still use @modelcontextprotocol/server-sentry?

It was archived on 28 May 2025 and is unmaintained.³ Use Sentry’s hosted server, or its stdio transport for self-hosted Sentry.

More on reading untrusted content safely: prompt injection and the research on indirect prompt injection. The same approach for Linear is in Linear MCP server security, and the general review is the ten-minute MCP config audit and the MCP security checklist.

To see what the rest of your agent setup can change, run npx deedglass scan in the repository (what the grade means), or watch the checks in the playground.

Written with AI assistance and checked against our claims register.