Sentry
Error monitoring and performance.
Verdict
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 iddestructive
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 iddestructive
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 sourcedestructive
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 projectdestructive
Permanently removes a specific debug information file (dif), used for symbolicating crash reports, from the specified sentry project and organization.
- Delete external issue by uuiddestructive
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 organizationdestructive
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 teamdestructive
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 ruledestructive
Deletes a specific metric alert rule within a sentry organization.
- Delete organization dashboarddestructive
Deletes a custom dashboard or tombstones (marks as deleted) a pre-built dashboard within a sentry organization.
- Delete organization discover querydestructive
Permanently removes a specific saved discover query (a configuration for exploring event data) from a sentry organization.
- Delete organization integrationdestructive
Permanently deletes a specific integration previously installed for the sentry organization.
- Delete organization issuedestructive
Permanently deletes a specific sentry issue, identified by its id, from an organization; this operation is irreversible and idempotent.
- Delete organization memberdestructive
Permanently removes a member from a sentry organization, revoking their access to that organization and all its associated projects.
- Delete organization monitordestructive
Deletes a sentry cron monitor or, if `environment` is specified, only specific environments within that monitor.
- Delete organization releasedestructive
Permanently and irreversibly removes a sentry release, including all its associated files, identified by its version from the specified organization.
- Delete org notification actiondestructive
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 iddestructive
Schedules a sentry project for asynchronous deletion within a specified organization, hiding it from most public views once the process begins.
- Delete project hookdestructive
Deletes a specific service hook from a sentry project using its organization, project, and hook identifiers.
- Delete project issuesdestructive
Permanently removes specified issues from a sentry project; if no issue ids are provided, it removes the oldest 1000 issues.
- Delete project keydestructive
Permanently deletes a specific client key (dsn) for a project, preventing it from being used to send events to sentry.
- Delete project monitordestructive
Deletes a sentry monitor, or optionally only its specified environments, for a given project.
- Delete project replaydestructive
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 ruledestructive
Permanently deletes a specific issue alert rule from an existing project within an existing sentry organization.
- Delete project team associationdestructive
Revokes a team's access to a sentry project; this operation is idempotent.
- Delete release filedestructive
Permanently deletes a specific file from an existing release, project, and organization; this action is idempotent.
- Delete release file by iddestructive
Permanently deletes a specific build artifact (e.g., source map, application bundle) associated with a release.
- Delete team by organization and team slugdestructive
Schedules a sentry team for asynchronous deletion, which releases the team's slug for reuse upon successful scheduling.
- Delete user emails by iddestructive
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 orgdestructive
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
- 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
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.
@sentry show me all critical alerts that fired in the last 24 hours across our production projects
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.
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.
@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
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.
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.
@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
**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.
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
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.
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.
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.