Why set up Sentry MCP access for Cursor?
Because the stack trace and the code sit in two windows, and the engineer is the only thing joining them. Sentry MCP access for Cursor lets an agent in the editor read the issue, open the file and propose the patch in one pass. The question is what else it can do to Sentry while it is in there. Use one governed endpoint, then decide, per role, which Sentry tools the agent may call.
MCP (the Model Context Protocol, the open standard an AI client uses to call tools) is how Cursor reaches Elaichi. Elaichi serves it at one address, https://api.elaichi.ai/mcp. The same string serves every organization. Which organization and which person a client reaches comes from the OAuth grant behind its token, not from the URL. Sentry is a connector in Elaichi's catalog, and its own page is Sentry. No Sentry token sits in anyone's editor config.
What goes wrong when the agent can write back to Sentry
Triage prompts invite writes. "Clean these up" reads to a model as an instruction to resolve, ignore or merge. A model holding a write tool will use it. One careless pass can retire a week of signal that three other engineers were watching.
Cursor's own controls help less than they look. Cursor asks for approval before using MCP tools by default. MCP calls follow the same Run Modes as terminal commands, so in Auto-review mode allowlisted MCP tools run at once (cursor.com/docs/mcp, checked October 2026). A per-tool allowlist cannot name one Sentry tool. Elaichi's connected tools do not arrive under their own names. The model finds a tool with search_tools and runs it with execute_tool, and connected tools are never listed one by one, however few there are. A permission set on execute_tool covers every connected-tool call made through it, whatever app is on the other end.
Hooks and admin policies sit at the same level. Cursor's beforeMCPExecution hook runs before each MCP tool call, receives the tool name and input, and answers allow, deny or ask (cursor.com/docs/hooks, checked October 2026). The name it sees is execute_tool, so the app appears only in the arguments. VS Code works per server too: its ChatAllowedMcpServers and ChatDeniedMcpServers policies name servers, and a deny entry takes precedence over an allow (code.visualstudio.com/docs/enterprise/manage-ai-settings, checked October 2026). Per-app control belongs in Elaichi.
The consent screen does not close the gap either. "Run your connected tools" (the mcp:tools scope) runs every tier of connected tool, writes and deletes included. "Delete data and remove access" covers Elaichi's own deletes, not a connected app's. Nothing on that screen holds a client to reading Sentry. A restriction does. In Elaichi, a restriction is a rule on a role or on one member saying which connectors and tools they may reach.
Restriction one: an allowlist for the engineering role
Write one allow rule naming Sentry whole. Add one for every other app that role needs. An allow rule naming a connector whole admits every tool on it. A layer's allow rules merge into one allowlist, so separate rules are fine.
The trap is what an allowlist does to everything else. Once a role carries any allow rule, every connector and tool its allow rules do not name is blocked for that role. That covers the whole catalog of 650+ connectors, not only the apps a rule mentions. So an allow rule naming Sentry alone cuts the role off from its ticket tracker. It is the same decision you face when you give the same team Linear through one endpoint. An allow rule that names nothing at all blocks every connector and tool for its target. That is a lockout, not a placeholder.
In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. To hold a squad off something, the rule goes on their role or on each member. Writing rules needs the restriction:manage permission and the restrictions plan feature, which Gold and Black both include. Among the built-in roles, Org Owner and Org Admin hold it. A role or restriction change reaches every surface within about two minutes. Write the rules before anyone connects a client.
Restriction two: block the Sentry tools that change state
Add a block rule on the same role. Name each Sentry tool that resolves, merges, deletes or reconfigures. Within a layer, a block always beats an allow. The whole-connector allow rule from the first restriction keeps Sentry reachable while these named tools stay shut.
Use a block rather than a narrower allow, for two reasons. A block rule matches a tool by name or by the operation it performs, so renaming a tool cannot slip it past. An allow rule matches only the operation Elaichi pinned when the rule was saved. An allow rule naming single tools also admits that connector for those tools only. Every new read tool the connector gains later is then blocked until someone edits the rule. The mechanics behind that asymmetry are set out in why blocks match tool names and allows do not.
One caution on block-only thinking. A layer with only block rules has no allowlist, so anything it does not name passes. Blocking three write tools leaves every write tool you did not name reachable. Open the connector's tool list in the console. It flags each tool as restricted or not for anyone who can read the connector. Name every non-read tool you find.
When the block bites, the refusal tells the caller the tool is restricted for their role. It also says an admin can lift it. From Cursor, a grant holding mcp:read or mcp:tools can file the engineer's own access request. An admin decides it in the console under Governance to Access requests. That needs member:manage and a fresh identity check, and no AI client can approve one. Approving creates an access grant for that one person. It lifts exactly the approved connector or tool out of their role rules, and nobody else's access changes. Grants have no revoke screen and no list, so treat an approval as a lasting decision.
Restriction three: a personal rule for contractors
For a contractor on the same engineering role, add a rule aimed at that member. A member is governed by both layers at once: their role's rules and the rules aimed at them personally. A connector or tool is reachable only when both admit it. A personal rule can therefore narrow what the role allows, never widen it.
A rule aimed at one member also needs the restriction:override permission, which Org Owner and Org Admin hold. A member flagged as a legacy override is the exception. Their own rules replace their role's rules. An admin clears that flag by editing the rule, which can only narrow them.
The companion decision is the connection. Every call through a connection uses the account it was connected with, whoever is calling. A shared Sentry connection therefore acts as its owner for everyone it reaches. Have each engineer connect Sentry with their own sign-in. Then Sentry's own permissions and the audit trail name the right person. For the wider choice between per-tool and per-app rules, see restrict one AI tool or the whole app.
How to connect Sentry to Cursor for debugging production errors
Five steps, in this order. The rules should exist before the clients do.
- In Elaichi, have each engineer connect Sentry with their own Sentry sign-in.
- Write the allow rule, the block rule and any member rule on the engineering role. Then allow about two minutes for the change to apply.
- In Cursor, add Elaichi as a remote MCP server. Cursor reads MCP servers from .cursor/mcp.json in a project and ~/.cursor/mcp.json in the home directory, and a remote entry is defined with a url field. Cursor supports OAuth for MCP servers that require it (cursor.com/docs/mcp, checked October 2026). The address is https://api.elaichi.ai/mcp, with no token in it.
- Each person signs in to Elaichi in the browser and approves their own grant, ticking "Run your connected tools".
- For a whole team, a Cursor Team admin can distribute shared MCP servers under Dashboard then Plugins & MCPs. Add to Team Marketplace makes a standalone server available in the Agent Window, IDE and CLI, where teammates install and configure it from Customize (cursor.com/docs/mcp, checked October 2026). Cursor's MCP Allowlist is Enterprise-only, configured in the team dashboard (cursor.com/docs/enterprise/model-and-integration-management, checked October 2026).
The rollout mechanics for a larger group are in one endpoint for a whole Cursor team. The wider engineering rollout is in how to roll out Cursor to an engineering team.
The audit filter that proves the restrictions held
Open the audit log in the console. Set the category to Assistant, type sentry in the search box and pick a date range. Over the API the same read is GET /audit-log with a category, a free-text q and a since time. Connected-tool calls sit in the Assistant category because their action is assistant.toolbox_tool. The MCP category holds grant events, not tool calls. That is the filter people reach for first, and it returns nothing.
Each row carries what a reviewer asks for. It names the acting person, the tool's advertised and catalog names, the connector, and the connection the call actually reached. It also records the tool's classification, how approval was given, the surface, and the MCP client id when the surface is mcp. The console's detail panel renders that as one sentence, opening with the client. Its "What it did" line reads Read data, Changed data or Deleted data. Export the filtered view as CSV, up to 10,000 entries, and narrow the range if it refuses.
Two honest limits. Elaichi keeps 90 days of audit history, and export to your own Datadog comes with the Black plan, which is launching soon. A longer trail needs that plan. And a call a restriction withholds writes no row at all, because the refusal happens before anything executes. The log proves what ran and who ran it, not every attempt that was stopped. What a reviewer should expect from it is set out in what an AI agent audit log must capture. A compliance reviewer can read the whole organization's log as an Auditor, which does not take a billable seat.
When a single developer should skip all of this
One engineer, one Sentry account, one app and nobody who needs the trail: that does not need a control plane. Configure the client by hand and move on. When you don't need an MCP gateway yet makes that case properly.
One limit to know before you lean on these rules. A restriction binds a connector's own identity and its declared forks, never the host it calls. Someone holding connector:create could build a new connector aimed at the same API, and a block on the Sentry connector would not catch it. That is the one permission Elaichi flags as high trust, and among the built-in roles only Org Owner and Org Admin hold it. Keep it narrow. The role and rule design behind it is covered in MCP governance, and the apps you can put under the same rules are listed in the connector catalog.
