developer-toolsoauth2

Sentry

Error monitoring and performance.

Verdict

Sentry via MCP lets the model pull error events, issue details, release adoption, and performance traces directly into the conversation. The "what's exploding right now" tool, plumbed into your AI loop. What we notice: the killer move is "what new errors showed up in this release" — the model can pull the issue list, group by frequency, and surface the top three regressions in one round trip. For triage, that beats clicking through Sentry's UI by a wide margin. The model is also good at correlating a stack trace with the recent diff in your repo when both MCPs are connected. Best for: post-deploy regression triage; weekly error review where the model summarises new vs recurring issues; correlating Sentry traces with recent commits or PRs; on-call handoff briefings that pull from real data instead of memory. Avoid for: replacing Sentry's alerting (the model isn't watching in real time — it answers when asked); deep performance analysis (the trace UI is genuinely good, the MCP feels like a downgrade); orgs where Sentry holds PII and the MCP boundary isn't reviewed. Practical frame: free tier covers small projects; team plans unlock the API. Token cost is moderate — stack traces eat tokens. The win shows up in the first "what broke since the last deploy" review where you don't have to switch tabs once.

Common use cases

  • Triage high-frequency errors before standup
  • Create alert rules when crash rate spikes
  • Invite contractors to organization teams
  • Pull performance dashboards for sprint reviews
  • Link external users to SSO identities

Integration

Vendor
Sentry
Category
developer-tools
Auth
OAUTH2
Tools
50
Composio slug
sentry

Tools

  • Access project information

    Retrieves detailed information for a sentry project, given its existing organization and project id or slug.

  • Add organization member via email

    Invites a new member (or re-invites an existing non-accepted member) to a sentry organization via email, allowing specification of organization and team roles.

  • Add or remove user email by id
    destructive

    Adds or removes a secondary email for an existing sentry user, determined by whether the email already exists for that user.

  • Add team member in organization

    Adds an existing member of an organization to one of its teams; the member must already belong to the organization, and the team must also belong to that organization.

  • Add team to project

    Grants a sentry team access to a sentry project within the specified sentry organization.

  • Create dashboard with widgets

    Creates a sentry dashboard with widgets for an organization; `organization id or slug` and specified `project` ids must be valid, and `start`/`end` datetimes (if absolute range) must form a logical iso 8601 range.

  • Create external user for organization

    Links a sentry user to an external identity provider's user within a sentry organization; the sentry user must be an organization member, an active integration for the provider must be configured, and `external id` is typically required for

  • Create organization alert rule

    Creates a sentry metric alert rule for an organization, mandating a 'critical' trigger, typically for a single project, where actions may require sentry integrations.

  • Create organization monitor

    Creates a new monitor (type 'cron job') within a sentry organization to track scheduled tasks, allowing configuration of its name, slug (which must be unique if provided), status, owner, and muting preferences for incidents.

  • Create organization team

    Creates a new team in a sentry organization, requiring either a 'slug' (preferred, as 'name' is deprecated) or 'name' to define the team.

  • Create project key with optional rate limiting

    Creates a new client key (dsn) for an existing sentry project, with optional custom rate limit configuration.

  • Create project rule for alerts

    Creates a sentry project alert rule by defining conditions, actions, and optional filters using specific json structures (detailed in parameter descriptions) to automate responses to event patterns for an existing organization and project.

  • Create project webhook subscription

    Registers a new webhook subscription for a sentry project to send http post notifications to a specified url for given events, provided the project has the 'servicehooks' feature enabled.

  • Create release deploy for org

    Creates a new deploy record in sentry to track the introduction of a release version into a specific environment.

  • Create release for organization

    Creates a new sentry release for an existing organization, associating it with specified projects that must belong to that organization.

  • Create scim group for organization

    Creates a new sentry team (scim group) within an organization where scim is enabled; a url-friendly slug is auto-generated from the `displayname` (e.g., 'my team' becomes 'my-team' by lowercasing and replacing spaces with dashes), and the t

  • Create sentry external issue link

    Links an existing sentry issue to an issue in an external service, or updates an existing link, requiring a configured sentry app installation `uuid`.

  • Create team project for organization

    Creates a new sentry project for an existing organization and team, allowing configuration of its name, slug, platform, and default alert rules.

  • Create user for SAML integration

    Creates a new sentry organization member via a scim request for saml integration; this action does not support setting secondary emails.

  • Delete an external team by id
    destructive

    Unlinks a previously established external team from a sentry team; this action does not delete either the sentry team or the external team.

  • Delete a project symbol source
    destructive

    Deletes a specific custom symbol source from a project.

  • Delete a team from an organization (SCIM v2)
    destructive

    Permanently and irreversibly deletes a specific team from a sentry organization via a scim v2 request, provided scim integration is enabled for the organization.

  • Delete dsyms for project
    destructive

    Permanently removes a specific debug information file (dif), used for symbolicating crash reports, from the specified sentry project and organization.

  • Delete external issue by uuid
    destructive

    Unlinks an external issue (e.g., from jira/github), identified by `external issue id`, from the sentry app installation specified by `uuid`.

  • Delete external user from organization
    destructive

    Deletes the link between an external user (e.g., from an sso provider) and a sentry user within the specified sentry organization.

  • Delete member from team
    destructive

    Removes an organization member from a sentry team, revoking their team-specific permissions, provided the member is currently part of that team.

  • Delete organization alert rule
    destructive

    Deletes a specific metric alert rule within a sentry organization.

  • Delete organization dashboard
    destructive

    Deletes a custom dashboard or tombstones (marks as deleted) a pre-built dashboard within a sentry organization.

  • Delete organization discover query
    destructive

    Permanently removes a specific saved discover query (a configuration for exploring event data) from a sentry organization.

  • Delete organization integration
    destructive

    Permanently deletes a specific integration previously installed for the sentry organization.

  • Delete organization issue
    destructive

    Permanently deletes a specific sentry issue, identified by its id, from an organization; this operation is irreversible and idempotent.

  • Delete organization member
    destructive

    Permanently removes a member from a sentry organization, revoking their access to that organization and all its associated projects.

  • Delete organization monitor
    destructive

    Deletes a sentry cron monitor or, if `environment` is specified, only specific environments within that monitor.

  • Delete organization release
    destructive

    Permanently and irreversibly removes a sentry release, including all its associated files, identified by its version from the specified organization.

  • Delete org notification action
    destructive

    Deletes a specific spike protection notification action for a sentry organization, where `action id` must be a valid action associated with the `organization id or slug`.

  • Delete project by id
    destructive

    Schedules a sentry project for asynchronous deletion within a specified organization, hiding it from most public views once the process begins.

  • Delete project hook
    destructive

    Deletes a specific service hook from a sentry project using its organization, project, and hook identifiers.

  • Delete project issues
    destructive

    Permanently removes specified issues from a sentry project; if no issue ids are provided, it removes the oldest 1000 issues.

  • Delete project key
    destructive

    Permanently deletes a specific client key (dsn) for a project, preventing it from being used to send events to sentry.

  • Delete project monitor
    destructive

    Deletes a sentry monitor, or optionally only its specified environments, for a given project.

  • Delete project replay
    destructive

    Permanently deletes a specific sentry session replay (a video-like reproduction of user interactions, including console logs and network activity) from the specified project and organization.

  • Delete project rule
    destructive

    Permanently deletes a specific issue alert rule from an existing project within an existing sentry organization.

  • Delete project team association
    destructive

    Revokes a team's access to a sentry project; this operation is idempotent.

  • Delete release file
    destructive

    Permanently deletes a specific file from an existing release, project, and organization; this action is idempotent.

  • Delete release file by id
    destructive

    Permanently deletes a specific build artifact (e.g., source map, application bundle) associated with a release.

  • Delete team by organization and team slug
    destructive

    Schedules a sentry team for asynchronous deletion, which releases the team's slug for reuse upon successful scheduling.

  • Delete user emails by id
    destructive

    Permanently removes a sentry user's email address; if multiple emails exist, sentry's api logic (e.g., primary or previously marked) determines which is deleted.

  • Delete user from org
    destructive

    Removes a scim-managed member from a sentry organization that has scim enabled, permanently revoking their access.

  • Fetch issue event by id

    Retrieves the 'latest', 'oldest', or 'recommended' event for a sentry issue, optionally filtered by environment(s).

  • Fetch organization alert rules

    Retrieves a list of active metric alert rules for an existing sentry organization, identified by its id or slug.

Setup

Setup guide

  1. 11. In Switchy, open the Space where you want Sentry available and click 'Add Integration' in the sidebar. 2. Search for Sentry and click 'Connect'. 3. You'll redirect to Sentry's OAuth consent screen — sign in with an account that has Owner or Manager role in the organization you want to link. 4. Grant scopes for project:read, project:write, event:read, member:read, member:write, and org:read (exact labels vary by Sentry plan). 5. After approving, Switchy redirects you back and confirms the connection. 6. Test it by typing '@Sentry list my projects' in a message — you should see a bulleted list of active projects. 7. To invoke specific tools, @mention Sentry and describe the task (e.g. '@Sentry show me unresolved errors in project frontend-web from the last 24 hours'). 8. If a tool fails with a permissions error, revisit Sentry's API token settings and verify the scopes match what the tool requires.

What teammates see: by default, memories from Sentry are scoped to the Space (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.

Works well with

Top models

Compatibility data appears once enough Spaces have used this MCP together with a given model.

How Switchy teams use it

Not enough Spaces yet to publish anonymised usage stats (we require ≥ 50 Spaces per week).

Starter prompts

Summarize Critical Errors

@Sentry show me all unresolved errors in the backend-api project with severity 'critical', sorted by frequency in the last 7 days.
Open in a Space →

Create Crash Rate Alert

@Sentry create an alert rule for the mobile-app project that triggers when crash rate goes above 2% in any 10-minute window, and send notifications to our #incidents Slack channel.
Open in a Space →

Invite Team Member

@Sentry invite alex@example.com to our organization as a member and add them to the backend-team with developer role.
Open in a Space →

Build Performance Dashboard

@Sentry create a dashboard called 'API Performance' for the backend-api project with widgets showing p95 response time and request throughput for the last 30 days.
Open in a Space →

Grant Team Project Access

@Sentry add the frontend-team to the new checkout-service project so they can see errors and configure alerts.
Open in a Space →

Example outputs

Illustrative - representative of the model's voice and quality, not literal recordings.

Prompt

@sentry show me all critical alerts that fired in the last 24 hours across our production projects

Output

Found 3 critical alerts in the last 24 hours: 1. **Error Rate Spike** (project: api-gateway) — Triggered at 2:14 AM UTC when error rate exceeded 5% over 10 minutes. 847 events recorded. 2. **Memory Leak Detection** (project: worker-queue) — Triggered at 9:03 AM UTC when heap usage crossed 85%. Still active. 3. **Latency Threshold** (project: checkout-service) — Triggered at 11:47 AM UTC when p95 latency hit 2.1s. Resolved after 18 minutes. All alerts sent notifications via Slack and PagerDuty per your configured actions.

Notes

This example shows Sentry's monitoring retrieval across multiple projects. Requires OAuth scope to read alert rules and issue data for the specified projects. The MCP aggregates recent alert history but does not modify alert configurations or silence notifications.

Prompt

@sentry create a new alert rule for the checkout-service project that pages on-call if transaction duration p95 exceeds 1.5 seconds for 5 minutes

Output

Created metric alert rule **"Checkout Latency SLA Breach"** for project `checkout-service`: - **Metric:** Transaction duration (p95) - **Critical trigger:** > 1.5s for 5 consecutive minutes - **Actions:** Send PagerDuty alert to on-call rotation, post to #incidents Slack channel - **Environment filter:** production only Rule is now active. You can view or edit it in the Sentry dashboard under Alerts → Metric Alerts.

Notes

This demonstrates Sentry's write capability for alert configuration. Requires OAuth scope to create alert rules and assumes PagerDuty/Slack integrations are already configured in your Sentry organization. The MCP cannot create integrations on the fly — those must exist beforehand.

Prompt

@sentry summarize the top 3 error groups from the mobile-app project this week and suggest which one we should prioritize based on user impact

Output

**Top 3 Error Groups (mobile-app, last 7 days):** 1. **NetworkTimeoutException** — 12,400 events, 3,800 affected users. Spike correlates with CDN latency issues on Tuesday. High user impact but external cause. 2. **NullPointerException in PaymentFlow** — 890 events, 890 affected users. 100% crash rate when triggered. Introduced in v2.4.1 release. **Recommend prioritizing** — blocking checkout for affected users. 3. **ImageLoadFailure** — 6,200 events, 1,100 affected users. Non-fatal, degrades UX but doesn't block core flows. Lower urgency. **Recommendation:** Fix PaymentFlow NPE first — it's a release regression with complete user-flow breakage.

Notes

This synthesis example pairs Sentry's issue data with AI reasoning to triage bugs by impact. The MCP retrieves error metadata (event counts, user counts, stack traces) but the prioritization logic comes from the AI's analysis. Requires read access to issue data and release tracking for the project.

Use-case deep-dives

On-call rotation handoff at 8-person team

When Sentry MCP streamlines incident triage during shift changes

A distributed engineering team runs 24-hour on-call rotations across three time zones. During handoff, the outgoing engineer needs to brief the incoming person on active alerts, recent spikes, and which projects are noisy. The Sentry MCP lets them query alert rules, pull project error rates, and check team assignments without leaving the handoff doc. The OAuth2 flow means each engineer authenticates once and the workspace retains access across shifts. This works until your org hits 15+ projects—at that scale, the 50-tool ceiling starts to feel limiting because you're toggling between project contexts constantly. If your on-call process lives in a single Slack thread and you rotate weekly, this MCP cuts handoff prep from 12 minutes to under 3.

Post-deploy smoke check for product team

Why this MCP wins for release validation workflows

A 5-person product team ships to staging every afternoon and wants a quick pulse-check before promoting to production. They need to see if the last deploy spiked errors in their two core projects, whether any new alert rules fired, and if the error distribution shifted across environments. The Sentry MCP surfaces project stats and recent alerts in a shared workspace prompt, so the PM and lead engineer can review together without opening the Sentry UI. The representative tools—project info, alert rules, dashboard creation—map directly to this 10-minute ritual. This breaks down if your deploy cadence is hourly or you need sub-minute latency on error spikes; at that tempo, you want webhooks pushing to Slack, not pull-based queries. For daily or twice-daily releases at small team scale, this MCP turns smoke-checking into a collaborative 2-minute standup agenda item.

Customer support escalation routing

When Sentry MCP helps support triage engineering ownership

A 6-person support team fields bug reports that sometimes require engineering escalation. They need to figure out which Sentry project owns the error, who's on that team, and whether an alert rule already exists for the issue pattern. The Sentry MCP lets support reps query project membership and alert configurations without admin access to the full Sentry org. The 'add team member' and 'create alert rule' tools mean they can loop in the right engineer or suggest a new alert in the same workspace thread. This assumes your support team is technical enough to interpret stack traces and project slugs—if they're non-technical, the MCP's 50 tools will overwhelm them and you're better off with a Zapier integration that routes based on keywords. For technical support teams at 10-30 person companies, this MCP closes the loop between 'customer reported a crash' and 'engineer owns it' in under 5 minutes.

Frequently asked

What does the Sentry MCP do in Switchy?

It lets your AI agents read error data, manage projects, invite team members, configure alert rules, and create dashboards across your Sentry organizations. You can automate incident triage, set up monitoring for new services, or pull crash reports into your workflow without switching to the Sentry UI. The MCP exposes 50 tools covering projects, teams, alerts, and user management.

Do I need admin access to connect Sentry via OAuth?

You need organization-level permissions to authorize the OAuth flow and grant the MCP access to projects, teams, and alert rules. Member-level access won't work for operations like inviting users or creating alert rules. The OAuth scopes Switchy requests map to Sentry's standard integration permissions, so check your organization settings if the connection fails during setup.

Can the Sentry MCP resolve issues or deploy fixes?

No. It reads error metadata, manages team assignments, and configures monitoring, but it doesn't mark issues as resolved or trigger deployments. If your agent identifies a fix, you'll still push code through your normal CI pipeline. The MCP is for observability and team coordination, not for changing application state or running release workflows.

Why use this instead of Sentry's API directly?

The MCP translates natural language into the correct API calls and handles pagination, authentication refresh, and parameter validation. Your agent can ask 'show me P0 errors from the checkout service this week' without you writing a script to parse filters, map project slugs, or retry rate-limited requests. It's faster for ad-hoc queries and one-off team tasks.

Who on the team should connect the Sentry integration?

Whoever owns your Sentry organization and understands which projects the team needs access to. That's usually an engineering lead or DevOps admin. Once connected, any Switchy user in your workspace can invoke the MCP, but the underlying Sentry permissions still apply—agents can't create alert rules if the connected account lacks that scope.

Compare with

Compare with anything else →
Data last verified 7 hours ago.Sources aggregated hourly to weekly. See docs/architecture/model-directory.md.