# How to roll out Cursor to an engineering team

> To roll out Cursor to an engineering team, connect Jira and Slack once, block deletes per role, pin the project and channel, then have engineers sign in.

**TL;DR** To roll out Cursor to an engineering team with Elaichi, connect Jira and Slack once, give engineers one role, block the deletes and webhooks, and freeze the Jira project and the Slack channel on a toolbox shared with the team in place of the connections. Each engineer then adds one organization-wide endpoint in their own Cursor and signs in with OAuth. GitHub is not in Elaichi's catalog, so it needs a custom connector or stays outside the rollout. Rule changes take about two minutes, and removing a member ends their access on the next call.

An engineer adds a Jira server to her Cursor config, pastes a personal API token, and her agent starts filing tickets. Within a month the snippet has spread around the team. Nobody can list who holds which token, or what each one can reach. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps.

To roll out Cursor to an engineering team on purpose, turn that order around. Connect the accounts and write the rules first, and let the editor come last. This playbook does it for Jira and Slack, and it is plain about GitHub, which Elaichi does not connect.

## How do you roll out Cursor to an engineering team?

Connect Jira and Slack once for the company, share engineers a toolbox of the tools they need, give them one role with rules on it, and then point Cursor at a single address. Each engineer adds that address in their own Cursor and signs in as themselves. Nobody pastes a token into a file.

Elaichi serves every connected account through one organization-wide endpoint, `POST /mcp`, which is standard MCP over Streamable HTTP behind OAuth. An endpoint is the web address a client calls. OAuth is the sign-in flow that gives a client a grant, a revocable permission tied to one person, instead of a copied secret. The grant is what differs between engineers, and it is what you revoke when someone leaves. Elaichi writes and hosts the Jira and Slack connectors itself, so your team runs no MCP server of its own.

Cursor reads its MCP servers from JSON: `~/.cursor/mcp.json` applies everywhere, and a project's `.cursor/mcp.json` applies to that project, per Cursor's [MCP documentation](https://cursor.com/docs/mcp). A remote server such as Elaichi is a `url` entry in that file, and Cursor supports OAuth for servers that require it. The same page says "MCP distribution and MCP policy are configured separately."

Distribution is the team admin's half. A Cursor team admin can add Elaichi as a shared Team MCP server under Dashboard, Plugins & MCPs, then choose Add to Team Marketplace. That makes it available in the Agent Window, the IDE and the CLI, where engineers install it from Customize. Linking a server to a marketplace "does not install or enable it for everyone". Policy is the other half: only Enterprise admins set the MCP allowlist. Cursor's [enterprise admin docs](https://cursor.com/docs/enterprise/model-and-integration-management) say adding a server to it "does not push it to users' machines".

So the per-engineer step is small but real: install or add the address once, then finish the OAuth sign-in. Cursor asks for approval before using MCP tools by default, so engineers see each call before it runs. Claude and ChatGPT take the same address if the company uses them too.

Behind the address, three layers decide what an engineer's agent can reach. Permissions are role-based access control (RBAC): about 38 action strings, such as `tool:execute`, grouped into roles, with exactly one role per member. Sharing decides which connections and toolboxes a member can use at all, and no admin role widens that view. Restrictions decide which connectors and which individual tools a target may reach, and most of this playbook is about them.

## Can Cursor reach GitHub through Elaichi?

No. GitHub is not in Elaichi's connector catalog, so this rollout cannot hand engineers governed GitHub tools.

There are two honest options. The first is a custom connector. Elaichi custom connectors are authored from JSON config, and creating one needs the `connector:create` permission. Elaichi flags that permission as high trust, because a custom connector can be pointed at any destination. Treat it as a small engineering project with an owner. Whoever writes the config decides which GitHub operations exist at all.

The second option is to leave GitHub out of this rollout. Engineers keep reaching GitHub the way they do today, and the governed address covers Jira and Slack.

GitHub does appear in Elaichi in one place, as a way to sign in to Elaichi itself, next to Google and Microsoft. That is an identity option, not a connector, and it gives Cursor no GitHub tools.

The rest of this playbook covers [Jira](/connectors/jira/) and [Slack](/connectors/slack/), which the catalog does have. If your team tracks work somewhere other than Jira, check the [ticketing connectors](/connectors/category/ticketing/) before you plan around one.

## What can an engineer do in Jira and Slack on day one?

Most of the work around the code: reading the issue, finding related bugs, filing new ones, noting what changed and telling the team.

| What the engineer asks Cursor for | Tool that runs |
| --- | --- |
| The issue being fixed, with its discussion | `get_single_jira_issue_by_id`, `list_all_jira_issue_comments` |
| Related bugs, found with a JQL query | `list_all_jira_search` |
| A new bug, filed without leaving the editor | `create_a_jira_issue` |
| A note on the issue saying what changed | `create_a_jira_issue_comment` |
| A log file attached to the issue | `create_a_jira_issue_attachment` |
| Last night's incident thread | `list_all_slack_conversation_replies` |
| The last time this error came up | `list_all_slack_search` |
| A status update in the team channel | `create_a_slack_chat` |

Two Jira reads make the writes go better. The `list_all_jira_search` tool takes JQL, Jira's query language, so "my open bugs in this sprint" is one call. The `list_all_jira_issue_createmeta` tool returns the fields each project requires, so the agent can check them before it calls `create_a_jira_issue`.

Other reads fill in context, such as `list_all_jira_projects`, `list_all_jira_versions` and `list_all_jira_labels` in Jira, and `list_all_slack_conversation_history` and `list_all_slack_files` in Slack.

The remaining writes are edits to issues, comments and messages: `update_a_jira_issue_by_id`, `update_a_jira_issue_comment_by_id` and `update_a_slack_chat_by_id`. There is also `slack_conversations_join`, which adds the Slack account to a channel. That one deserves a decision of its own, since it widens the set of channels the account belongs to.

## Which Jira and Slack tools should you block first?

The deletes, the webhooks and the admin reads that no engineer needs. Write each as a block rule on the engineer role, and leave everything else open while the pilot runs.

A restriction is a rule about which connectors and which individual tools a target may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So until you write the first block, restrictions narrow nothing at all. Start with these:

- `delete_a_jira_issue_by_id`, whose description notes that `deleteSubtasks` set to true removes the subtasks with the issue. One call can take a parent issue and everything under it.
- `delete_a_jira_issue_comment_by_id`, because the comments on a bug are where its history lives.
- `create_a_jira_webhook` and `delete_a_jira_webhook_by_id`. Creating a webhook tells Jira to send events to a URL, which makes it a quiet way to move data out. No task an engineer runs from Cursor needs either one.
- `delete_a_slack_chat_by_id`, which deletes a message by channel and timestamp. Slack's [chat.delete reference](https://docs.slack.dev/reference/methods/chat.delete/) ties what a call can remove to the token behind it, so its reach depends on who connected Slack.

Then weigh the admin reads. In Jira, `list_all_jira_audit_logs` returns Jira's own audit records and `list_all_jira_licenses` returns the instance's licensing. In Slack, `list_all_slack_team_billing_info` returns the billing plan, and `list_all_slack_team_access_logs` returns each person's IP address, user agent and location. That last one is personal data about colleagues, and no engineering task needs it.

A block rule matches the advertised tool name or the operation Elaichi pinned against the catalog when the rule was saved. An allow rule matches the pinned operation only. Whoever edits a connector's documentation can rename a tool, so a name is a label the governed side controls, and [rules bind the operation instead](/blog/block-matches-name-allow-matches-operation/).

Hold off on allow rules until you mean them. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. A half-drafted allow rule with no tools in it locks the whole engineering team out.

Rules resolve in layers: a user rule first, then a role rule, then the org default. Inside the winning layer, a block always beats an allow. A rule on a user replaces the role rules for that user rather than adding to them. Give the engineering manager her own exception and you have replaced her role rules, so restate the blocks she should keep.

OAuth scopes add a second lock on each engineer's grant. A connected tool whose method is a delete needs `mcp:destructive` as well as `mcp:tools`. A tool classified `forbidden` is reachable under no scope at all. A new block takes about two minutes to reach every engineer's session, so wait that long before you test it.

## How do you pin Cursor to one Jira project and one Slack channel?

Freeze the argument that picks the destination. On `create_a_jira_issue`, freeze the project inside `fields`. On `create_a_slack_chat`, freeze `channel` to the team's channel.

Frozen parameters are values fixed on a toolbox entry, where a toolbox is a saved set of tools and accounts an agent works through. Freezing has two effects. The frozen key is stripped from the schema the model sees, so Cursor is never asked to choose a project or a channel. At execution the frozen value is merged over the caller's arguments. An agent that sends the key anyway still lands where you pinned it. The order runs entry defaults, then the caller's or model's arguments, then frozen values last.

One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. An engineer who also holds `use` on the Jira or Slack connection, directly or through a team or organization share, reaches the same tools unfrozen. A block on those tools does not close the gap, because restrictions apply to toolbox entries too and would withhold the frozen entries as well. Leave the connections unshared, and share the toolbox with the engineering team.

The `create_a_jira_issue` tool's description reads "Requires fields and update parameters". In Jira's [Create issue](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-post) API, the target project is one of the entries in `fields`. Elaichi's frozen parameters work over a tool's flattened argument space, so you can pin the project and leave the summary and description free. An agent working on the payments service then files into the payments project and nowhere else.

The `create_a_slack_chat` tool "Requires channel". Slack's [chat.postMessage reference](https://docs.slack.dev/reference/methods/chat.postMessage/) defines that argument as the channel, private group or direct message to send to. That is the choice you do not want a model making. Freeze it to the team's channel, and the agent cannot post to the company-wide one.

Two neighbors deserve the same care. Freeze `channel` on `update_a_slack_chat_by_id` as well. Block `slack_conversations_join`, or freeze its `channel`, so the Slack account stays in the rooms you chose. The [IT team's Slack playbook](/blog/it-team-claude-slack-messaging/) goes further on pinning a posting channel.

Frozen values and restrictions do different jobs. A restriction decides whether a tool is reachable at all. A frozen value decides where a reachable tool can write.

## Why can't Cursor move a Jira issue to Done?

Because the Jira connector's update tool does not perform transitions. The description of `update_a_jira_issue_by_id` says so directly: "issue transition is not supported here".

That follows Jira's own API. Atlassian's [Edit issue](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-put) reference says a transition is not supported there, and sends callers to a separate [Transition issue](https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-transitions-post) operation. In Jira, moving an issue from To Do to Done is a workflow step, not an edit to a field. A transition can even carry its own screen of fields.

Plan the rollout around it. Status changes stay with people, or with automation you configure inside Jira. The agent can still read the statuses a project uses through `list_all_jira_status`, and it can comment with what changed through `create_a_jira_issue_comment`. Tell engineers before the pilot that closing the ticket is still their job.

## What does Cursor's tool list show once Jira and Slack are connected?

Two meta-tools and Elaichi's own operations, but no Jira or Slack tool by name. In Elaichi, connected tools are never listed one by one, however few there are. Cursor looks a Jira or Slack tool up through `search_tools`, then calls it through `execute_tool`, which adds no privilege: the call passes every check a direct call would. [Why connected tools stay out of the list](/blog/context-window-problem-mcp-tools/) explains the design.

A tool a restriction removes is invisible. It looks exactly like a tool the connector never had, so a restricted `delete_a_jira_issue_by_id` never turns up in a search.

When an engineer cannot find a tool they expected, check the dull causes first. What an engineer can see is filtered by their role and by the scopes on their grant. A Jira connection that is `pending` or `needs_reauth` contributes no tools at all, so it looks absent rather than broken. Search also has [a floor that returns nothing rather than the wrong app](/blog/search-tools-ranking-floor-idf/).

## Who changed that Jira issue, and was it an agent?

Every Jira and Slack call lands in Elaichi's append-only audit log, which holds one entry per tool-call attempt, succeeded or failed. Each record shows which Jira or Slack account the call actually reached, and a call from Cursor is recorded under the engineer who signed in, with surface `mcp` and Cursor named as the OAuth client. [What an AI audit log must capture](/blog/what-an-ai-audit-log-must-capture/) covers the rest of the record.

## What order should a Cursor rollout follow?

Accounts and rules first, the editor last. A rollout that starts in Cursor spends its first week granting exceptions, and every exception is a rule written in a hurry.

1. Connect the company's Jira and Slack accounts once in Elaichi, from the [connector catalog](/connectors/) of 500+ connectors.
2. Pin the day-one Jira and Slack tools into a toolbox and share it with the engineering team. Leave the connections themselves unshared, so every engineer's call runs through the toolbox. Nobody reads the secrets back.
3. Create one engineer role carrying `tool:execute` and nothing the job does not need. Without `tool:execute` the tool list is empty, and each member holds exactly one role, so this one has to be complete.
4. Write block rules on that role for the Jira and Slack deletes, both webhook tools and the admin reads you decided against.
5. Freeze the project inside `fields` on `create_a_jira_issue`, and `channel` on `create_a_slack_chat`, in the toolbox entries engineers will use.
6. Wait about two minutes for the rules to reach every surface.
7. Have a Cursor team admin add the endpoint as a Team MCP server and list it in the team marketplace. If an Enterprise admin runs Cursor's MCP allowlist, add the endpoint there too. Then have two engineers install it in their own Cursor and sign in.
8. Ask one pilot agent to delete a throwaway issue in a sandbox project. It should find no tool for the job, and an attempt through `execute_tool` is refused and logged.
9. After a day, read the pilot's audit entries and adjust the rules.
10. Invite everyone else with the role preassigned on the invite link. Give the compliance reviewer the Auditor seat, which is free and read-only.

Past the pilot, the joining path matters as much as the rules. Elaichi has SAML and OIDC single sign-on (SSO) built in. It also has SCIM v2, the standard for syncing users and groups from a directory. Group-to-role mapping lets a directory group carry the engineer role.

## What happens to a developer's Cursor access when they leave?

It ends with their membership. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The grant is checked on every call with no cache, so the next call from their Cursor fails. A SCIM deprovision from your directory suspends the member, which ends access the same way. Removing them is a separate step an admin takes in Elaichi.

Do not plan a departure around a role downgrade. Role and restriction changes pass through a short cache and take about two minutes. That suits tuning rules, not an exit.

The Elaichi address left in their Cursor is harmless on its own. Everyone uses the same address, and the grant was the part that belonged to them.

Removal also runs a preflight. If a toolbox entry depends on a personal connection the developer owned, Elaichi refuses the removal. It goes through once someone hands that connection to the org, a team or a colleague, or deletes it. If the developer pinned the team's toolbox entries, those entries stop resolving for every engineer until someone re-pins them, which offboarding flags as a warning. Their Atlassian and Slack accounts are a separate step in those tools. The full sequence, contractors included, is in [offboarding a member who holds MCP connections](/blog/offboarding-when-the-agent-holds-access/).

## Why not use Atlassian's or Slack's own MCP server?

Both vendors run one, and a team that needs only one of the two apps may be better served by that vendor's server. Atlassian publishes an "Official remote MCP server for Atlassian" that connects Jira, Confluence and more "to Claude, ChatGPT, Cursor, VS Code, and other AI tools using OAuth 2.1 or API tokens". Its README adds that "every action respects the user's existing access controls" ([Atlassian's repository](https://github.com/atlassian/atlassian-mcp-server), read October 2026). Slack's server answers at `https://mcp.slack.com/mcp`, and Slack says "Workspace admins can approve and manage all MCP client integrations" ([Slack's MCP server docs](https://docs.slack.dev/ai/slack-mcp-server/), read October 2026).

Where they win is plain. Each runs under its own app's permission model, and neither puts a second vendor between Cursor and your data.

What Elaichi adds is the layer across the two apps. Engineers add one address rather than two servers, and the same address serves Claude and ChatGPT. The engineer role's blocks on Jira and Slack deletes are written once, in one place. Frozen parameters on the shared toolbox pin the Jira project and the Slack channel. One audit trail covers both apps, and one removal or suspension in Elaichi ends a developer's access to both on their next call. Neither page describes a rule that covers Jira and Slack together, or a frozen argument, so ask each vendor if you need one.

The Jira connector page lists every Jira tool Elaichi serves, with the setup for Claude, ChatGPT and Cursor.

[See the Jira connector](/connectors/jira/)

## When does a Cursor rollout not need any of this?

When Cursor only touches local code, or when the whole team is a handful of engineers on their own accounts. A Cursor install that reads local files and writes local code reaches no SaaS account. There is nothing for a control plane to govern and no shared credential to manage.

Size matters too. Take five engineers who all administer one Jira project, with no contractor and no reviewer asking who did what. Personal setups with local MCP servers cost them less. That is a defensible choice, and the controls in this playbook would buy them little.

If your only question is which MCP servers engineers may run, an Enterprise admin's allowlist in Cursor may be the whole answer.

A second Jira site, a contractor or an auditor asking who closed a ticket changes the math. So does a team too big for anyone to know every config. The threshold test in [when you don't need an MCP gateway yet](/blog/when-you-dont-need-an-mcp-gateway/) applies to Cursor unchanged.

One limit holds at any size. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. A poisoned Jira comment can still steer a model toward a tool. Restrictions decide whether that tool exists for the engineer, and the attempt is logged either way.

[The four shapes an MCP gateway takes](/blog/what-is-an-mcp-gateway/) shows where this approach sits. The [sales team's Salesforce playbook](/blog/sales-team-chatgpt-salesforce-accounts/) runs the same order with ChatGPT, and [use cases](/use-cases/) lists what each of the twelve teams typically connects.

## FAQ

### Does each engineer need their own MCP server URL to use Cursor with Elaichi?

No. Elaichi serves every connected account through one organization-wide endpoint, POST /mcp, behind OAuth. Every engineer adds that same address in their own Cursor and signs in as themselves, and what differs is each engineer's grant and the role they hold. A Cursor team admin can share the address through the team marketplace, and an Enterprise admin can allowlist it, but neither installs it on anyone's machine.

### Can Elaichi connect Cursor to GitHub?

No. GitHub is not in Elaichi's connector catalog, so a Cursor rollout through Elaichi covers tools such as Jira and Slack and leaves GitHub out. The route inside Elaichi is a custom connector authored from JSON config. Creating one needs the connector:create permission, which Elaichi flags as high trust because a custom connector can be pointed at any destination. GitHub also appears as a way to sign in to Elaichi itself, which is identity only and gives Cursor no GitHub tools.

### Can Cursor move a Jira issue to Done through Elaichi?

No. The Jira connector's update_a_jira_issue_by_id tool states that issue transition is not supported, which matches Jira's REST API, where a transition is a separate operation from editing an issue. An agent can still read a project's statuses and comment on the issue with what changed. Moving the issue through the workflow stays with a person or with automation configured inside Jira.

### How do you stop Cursor from posting in the wrong Slack channel?

Freeze the channel argument on the create_a_slack_chat tool in the toolbox entry engineers use. In Elaichi a frozen key is removed from the schema the model is handed, so the model is never offered a channel to pick. At execution the frozen value is merged over the caller's arguments, so sending the key anyway changes nothing. The freeze holds only for calls through that toolbox, so share the toolbox with engineers and leave the Slack connection unshared. Freeze channel on update_a_slack_chat_by_id as well if message edits should stay in the same place.

### How long does a new Jira block rule take to reach engineers in Cursor?

In Elaichi, a restriction or role change takes about two minutes to reach every engineer's session, on the MCP endpoint, in the console and over REST alike, because rules resolve through a short cache and edge distribution. Grant revocation, member removal and member suspension act on the next call. Wait that long before testing a new block from Cursor.

### Can Elaichi stop prompt injection reaching Cursor through a Jira ticket?

No. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. An MCP server never sees the prompt a person typed, so it has nothing to screen. What still applies to every Cursor call is role-based access control per operation, the forbidden tool classification, output redaction, OAuth scope limits and a logged entry for every attempt. A poisoned ticket can persuade a model to try a tool, and governance decides whether that tool is reachable.

## Read next

- [Xero in Claude, without letting it edit invoices](/blog/finance-team-claude-xero/) — Xero in Claude for a finance team: analysts read invoices and reports, and no assistant can edit or void an invoice unless one named person is allowed to.
- [Should marketing get HubSpot inside ChatGPT?](/blog/marketing-team-chatgpt-hubspot-campaigns/) — Yes: marketing can have HubSpot inside ChatGPT to read contacts and campaigns and draft work, with email sends and deletes blocked and the portal pinned.
- [Each rep's own Salesforce access, in ChatGPT](/blog/sales-team-chatgpt-salesforce-accounts/) — Salesforce access in ChatGPT works per rep: each call runs on the rep's own connection, so Salesforce's sharing rules decide which accounts they see.