MCP server · Sentry
Sentry MCP Server
Sentry's official MCP server for querying errors, issues and traces from an agent session, offered as a hosted remote server.
What it is, and what it costs you
Connecting error monitoring to an agent closes a genuinely tedious loop: the agent can read the actual exception, its stack trace, its frequency and affected releases, and then work on the code that produced it — rather than being handed a paraphrased description by a human intermediary. For triage and root-cause work the productivity difference is real.
The data being connected is sensitive in a way teams underestimate. Error reports are, almost by definition, snapshots taken at the worst moment — local variables, request parameters, headers, user identifiers, and occasionally credentials that were in scope when the exception fired. Scrubbing rules help and are worth investing in, but no team's scrubbing is complete, and the agent reads whatever survived it.
Sentry offers this as a hosted remote server, which is the right default for most organisations: nothing to run locally, authorization is a revocable grant rather than a pasted token, and access is bounded by the scopes agreed at consent. The trade-off is that queries and results transit an additional service, so the retention question applies to the agent host as well as to Sentry.
The injection angle is that error data is partly attacker-controlled. If a user-supplied value appears in an exception message — a malformed input, a crafted parameter — then anyone able to trigger an error in your application can place chosen text where an agent will later read it.
Capability profile
What this server can reach, and why a security team cares. These are capabilities the server has by design — derived from the publisher's documentation, not from a scan.
- error and issue read
Stack traces and captured context routinely include request data, user identifiers and secrets that escaped scrubbing.
- trace and performance query
Reveals internal service topology, endpoint names and dependency structure.
- attacker-influenced content
Exception messages can embed user-supplied values, making error data an indirect injection channel.
- issue state changes
Where write scopes are granted, the agent can alter triage state and assignment.
Restrict this before you roll it out
- Tighten data scrubbing before connecting
Whatever Sentry retains is what the agent reads. Server-side scrubbing rules are the control, and they are worth auditing first.
- Grant read-only, project-scoped access
Triage rarely needs write scopes, and scoping to specific projects contains what an injected session can enumerate.
- Prefer the hosted remote server
A revocable OAuth grant with explicit scopes is easier to govern than a long-lived token in a local config file.
Vincosha Assay assessment
not yet assessedWe have not published a scan verdict for Sentry MCP Server.
Everything above is a capability profile compiled by hand from the publisher's own public documentation on 2026-07-25. It describes what this artifact can reach and what to restrict before rolling it out. It is not a security verdict, and it should not be read as one.
When Vincosha Assaypublishes an assessment for this artifact it will appear here with a verdict, the findings behind it, and the date it ran. We would rather leave this space empty than fill it with a guess — inventing a security verdict about somebody else's software would be both wrong and dangerous.
What an assessment covers
- prompt-injection patterns in descriptions and instructions
- credential reads and outbound egress in bundled code
- over-scoped permissions and manifest claims
- typosquatted and impersonating names
- tool-manifest drift since the last approval
- content hash against the version you approved
Sources
This profile was compiled from the publisher's own documentation. Products change — verify against the source before making a decision that depends on a specific detail.