Secure Sentry access for AI agents
Search and triage Sentry issues and events, update issue status and assignment, and run Seer root-cause analysis, using Sentry's official MCP server.
Through Sentry, agents can look up organizations and projects, search issues and events, pull up a specific issue/trace/span, and kick off Seer's automated root-cause analysis — useful for triage and debugging without giving an agent free rein to resolve, ignore, or reassign issues on its own. Every call runs through your policies and is logged for audit.
Server URL: https://mcp.sentry.dev/mcp
Setup
- Navigate to Resources and click Add Resource
- Select Sentry from the catalog
- Choose Per-org dynamic registration, the only mode Sentry offers — picking the card installs the resource with all tools pre-configured
Each user connects their own Sentry account via OAuth when they first use a Sentry tool. Navigate to Connections to manage linked accounts.
Sentry's own organization, project, and team permissions still apply — the gateway never widens access beyond what the authorizing user could already do in Sentry, it only narrows it.
Dynamic client registration
This is the mode card labeled Per-org dynamic registration on the Sentry configure page. No app needs creating on Sentry's side and no client ID or secret to enter: the gateway registers an OAuth client with Sentry per organization at install time.
Available tools
| Tool | Description |
|---|---|
find_organizations | Find organizations the user has access to, or look up an organization's slug |
find_projects | Find projects in an organization, or look up a project's slug |
search_issues | Search for grouped issues by status, level, assignment, age, or other Sentry syntax |
search_events | Search events, logs, spans, metrics, profiles, or replays; also used for counts/stats |
get_sentry_resource | Fetch an issue, event, trace, span, AI conversation, replay, monitor, or snapshot by URL/ID |
analyze_issue_with_seer | Run Seer's automated root-cause analysis on an issue and get suggested code fixes |
update_issue | Resolve, reopen, ignore, or reassign an issue |
search_sentry_tools | Search Sentry's long-tail tool catalog (releases, teams, DSNs, attachments, and more) |
execute_sentry_tool | Execute a tool discovered via search_sentry_tools |
Two of these deserve a second look before you allow them broadly: update_issue is the one tool that mutates issue state, and execute_sentry_tool can run any tool search_sentry_tools surfaces — including long-tail write operations not listed above — so denying it is the only way to be sure no Sentry write reaches an agent.
Policy examples
Rules are evaluated top to bottom and the first match wins. Allow rules on their own restrict nothing — your org starts with a seeded Allow all rule, so any tool your allows don't cover still falls through to it. Narrowing access needs a catch-all deny scoped to this resource, ordered below the allows. See Policies.
- Read-only Sentry for everyone. Deny
update_issueandexecute_sentry_toolscoped to this resource, above the seeded Allow all rule. Reads (find_*,search_*,get_sentry_resource,analyze_issue_with_seer) keep working. - Scope one agent to issue triage. Deny
*scoped to this resource and to that agent, then allowfind_organizations,find_projects,search_issues,search_events,get_sentry_resource, andanalyze_issue_with_seerabove the deny — ordered above it, since new rules insert at the top and evaluation is first-match-wins.
Next steps
- Create a policy — start from the read-only pattern in Policy examples above.
- Policies — how rule order, scoping, and the seeded Allow all rule interact.
- Connections — manage the Sentry accounts your users have linked.