Sentry

What a member can do

With Sentry connected, a member can work in the Sentry organisations its Sentry account belongs to: search issues, events and traces, read an issue's details and stack trace, and update issues (resolve, assign, ignore), as far as that account's own role in Sentry allows.

Each task names the Sentry tools it may call. sentry on a task means every tool Sentry's server offers; a name such as sentry.search_issues means that tool alone. A tool the task does not name is refused, whatever the connection allows. If Sentry's server does not answer when a run starts, the run carries on rather than failing, and its log records tool.not_offered.

A member fixing what Sentry reports does the code itself in a workspace.

Who connects it

A Sentry connection is made with Sentry's own OAuth, so it acts as the Sentry user who approved it when it was connected. Everything the member does in Sentry is recorded against that user, and it can reach only what that user can.

A connection can sit on the enterprise, a team, a member, a role or a task, and the one further down replaces the one above: task, then role, then member, then team, then enterprise. Connect a member's own while Sentry is signed in as that member's own Sentry account, and what it resolves or assigns shows under its own name. Connect it while signed in as yourself, and it all shows as you.

A connection on anything but a task also reaches the chat of every member it covers.

What waits for you

In a run, nothing on Sentry waits for you unless the task declares a gate on it. To approve each change before it happens, gate the tools that change something, such as sentry.update_issue, on the task. See Gates and tool scopes.

In a chat, a Sentry tool that Sentry does not mark as read-only asks you before it runs, unless you chose Always allow for that member and tool.

Setup

Connect it

Work in one browser window throughout: Sentry returns to the portal in the window you started from.

1. In the portal, on the member's page → Tools (or Tools, for another layer), choose Add tool.
2. Kind: MCP. Tool type: sentry.
3. MCP server URL: https://mcp.sentry.dev/mcp. To keep the member to one organisation, add its slug: https://mcp.sentry.dev/mcp/<organisation-slug>, or to one project, https://mcp.sentry.dev/mcp/<organisation-slug>/<project-slug>.
4. Auth: OAuth. Leave the client ID, client secret and scopes blank: Sentry registers Zero Human OS as a client by itself.
5. Choose Connect with OAuth. Sign in to Sentry as the account the member should act as, and approve.
6. Name the tools on the task, sentry for all of them or each by name.
7. Check it. Run a task that searches Sentry's issues. The run page shows the call and what Sentry returned.

Custom props, for your organisation

Sentry's tools take the organisation as an argument, organizationSlug. Set it once on the binding, and every task and chat that uses the binding works in that organisation without naming it: open the binding on Tools, press Custom props at the top right of the form, and add this key (or send it as props over the API):

The model is never asked for it, and a tool that takes no organisation is sent nothing. The catalog's Sentry triage task expects it.

Giving a member its own Sentry account

A member joins Sentry the way a person would: invite the member's Zero Human address to your Sentry organisation, with the role and teams it needs. The invitation, and every other Sentry email for the member, appears in the Inbox on its member page in the portal. Accept it and set the account up in a separate browser profile or a private window, where Sentry is not signed in as you, then connect the member's binding from that same window, signed in to the portal as yourself.

Troubleshooting