What it is
Sentry’s first-party connector: from inside the agent you can search issues, read error and trace detail, and hand a problem to Seer for root-cause analysis, against your own authenticated Sentry organization.
How it was vetted
Booted the published package (@sentry/mcp-server 0.37.0) and read the repo at
commit ce099fd (2026-07-10). For a connector to a data service, the audit is about
what it reaches and what it emits.
- Auth is sensible. On
sentry.io, no token. It runs a device-code OAuth flow and you approve access. Self-hosted instances take--access-tokenand--host. Nothing is hard-coded and nothing is required in the clear. - It surfaces production error data. The tools read your org’s issues, errors, and traces. That data, often containing stack frames, request payloads, and user identifiers, flows into the model context. That’s the feature; just treat the context as if it now contains your error stream, because it does.
- The server has its own telemetry. It reports its own operation to Sentry via a
built-in DSN (a company dogfooding its product). It’s disclosed in
--helpand overridable with--sentry-dsn. - Agent mode trims the surface.
--agentexposes only a singleuse_sentrytool, which keeps token injection small when an agent doesn’t need the full set.
