What does it take to connect Elaichi to Cursor?
To connect Elaichi to Cursor, add one URL, https://api.elaichi.ai/mcp, as a remote MCP server and sign in with OAuth. Each developer can add it to their own mcp.json, or a Cursor team admin can share it once as a Team MCP server. Either way there is no API key, no header and no per-developer URL.
An engineering team that adopts Cursor usually ends up with one JSON block per laptop. Each block points at a different server with its own token. Forty developers means forty copies of the wiring, and nobody holds a list of what they contain. One URL behind OAuth replaces the copies, because the address is the same for everyone and only the grant behind each sign-in differs.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Cursor speaks it, as do Claude and ChatGPT, and the specification is public. Elaichi serves every connected SaaS account through one organization-wide endpoint, POST /mcp, behind OAuth.
How does each developer add Elaichi in mcp.json?
With a short entry that holds only the URL. Cursor reads MCP servers from ~/.cursor/mcp.json, which applies in every project, or from a project's .cursor/mcp.json, which applies to that project (Cursor's MCP docs, checked October 2026).
{
"mcpServers": {
"elaichi": {
"url": "https://api.elaichi.ai/mcp"
}
}
}Add the entry alongside any servers already in the file. It has no headers block and no key in env. Cursor's docs say it "supports OAuth for servers that require it". Cursor registers itself with Elaichi as an OAuth client through dynamic client registration, the standard defined in RFC 7591, which Elaichi supports. So nobody pastes a client ID or a secret, and each developer authenticates to Elaichi as themselves.
A project file is safe to commit. It holds a public URL and nothing else, so every clone of the repository carries the same entry and no credential.
Can a Cursor admin share Elaichi with the whole team?
Yes, as a Team MCP server, though each developer still installs it and signs in. Cursor's docs separate the two jobs: Team admins can distribute shared MCP servers, and Enterprise admins set MCP policy.
- Under Dashboard > Plugins & MCPs, configure Elaichi as a shared Team MCP server, using the URL above.
- Under Team MCP Servers, select Add to Team Marketplace. That makes it available in Cursor's Agent Window, IDE and CLI.
- Ask developers to install it from Customize and sign in.
The docs are plain that a marketplace listing is an offer, not an install: linking a server to the marketplace installs and enables it for nobody. What an admin saves is the copying and the typos, not the sign-in. Every developer still authenticates as themselves, and that is the point, because each grant belongs to one person.
What changes if your Cursor Enterprise org runs an allowlist?
Add the Elaichi URL to it, or Cursor blocks the server. Enterprise admins choose which MCP servers and tools the team may run under Team Settings > MCP Configuration. Cursor's enterprise docs say that when an allowlist is active, "only servers matching an allowlist entry can run" (Cursor enterprise docs, checked October 2026).
An allowlist approves a server but does not distribute it. The same page says that adding a server "does not push it to users' machines", so each team member still configures it in their own Cursor settings. Run the two together: the allowlist decides what may run, and the marketplace offers Elaichi to install.
The allowlist can name tools too, but it cannot see inside Elaichi. Every connected tool reaches Cursor through execute_tool, so a Cursor rule cannot tell a Jira read from a Jira delete. Write that distinction in Elaichi's restrictions instead.
Why does Cursor show so few Elaichi tools?
Because connected tools are not listed one at a time. In Elaichi, connected tools are never listed one by one, however few there are. Cursor's agent looks a tool up with search_tools and runs it with execute_tool, so a short tool list is the expected view, not a failed connection.
execute_tool is only a naming indirection. It unwraps to the same tool name and arguments and passes the same checks as a direct call. Search is lexical, and it returns nothing rather than a tool from an app the developer never connected. The relevance floor behind search_tools explains how.
Where do the connected accounts come from?
From Elaichi, not from Cursor. A developer or an admin connects each SaaS account once, from a catalog of 600+ connectors that Elaichi serves, most of them written by Elaichi itself. Nothing about an account lives in mcp.json, and your team runs no MCP server per app.
Credentials stay out of Cursor entirely. A separate credential service holds each account's secrets, encrypted at rest, and owns token refresh. A failed refresh marks the connection needs_reauth, so it shows up as a connection to fix rather than a silent failure.
What decides which tools a developer's Cursor can call?
The developer's role, what has been shared with them, and restrictions, checked on every call. A role is a set of permissions, with exactly one role per member, and tool:execute gates the whole endpoint. Sharing makes a connection that someone else owns usable by a developer.
Restrictions decide 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. A rule aimed at a member can only narrow what their role allows, and never replaces or loosens a role rule. Watch for one trap: the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything.
Frozen parameters pin an argument the model must not choose, such as the Jira project an engineer may write to. A frozen key is removed from the schema Cursor sees, and its value is merged over whatever the model sends. 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. A role or restriction change takes about two minutes to apply, and the guide to offboarding AI access sets out which changes land on the next call instead.
Will Cursor run an Elaichi tool without asking?
Not by default. Cursor's docs say it "asks for approval before using MCP tools by default", and that clicking the arrow next to the tool name shows the arguments. For an Elaichi call the prompt names execute_tool, and the real tool is in those arguments, so expand them before you approve a write.
Cursor's Run Modes can loosen that. In Auto-review mode, the docs say, allowlisted MCP tools run straight away and everything else goes to a classifier. Treat the approval prompt as a convenience, not the control.
The guarantee sits on Elaichi's side. A tool that a restriction withholds cannot be called, however the prompt is phrased. OAuth scopes set a ceiling: reads need mcp:read, writes mcp:write and deletes mcp:destructive. A tool classified forbidden is reachable under no scope.
How do you see what Cursor did?
In Elaichi's audit trail. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none), naming the account the call reached and the OAuth client it came through, with Cursor marked verified. The call is recorded under the engineer who signed in. What an AI agent audit log must capture covers the fields.
The Auditor role is free and read-only, so a compliance reviewer can read the trail without a paid seat. Beyond the in-app trail, export to your own Datadog comes with the Black plan, which is launching soon.
What happens to a developer's Cursor access when they leave?
It ends on the next call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change, so the next request from that developer's Cursor fails. A SCIM deprovision from your identity provider suspends the member, which has the same effect.
The mcp.json entry left on the laptop does not matter. It holds a public URL and no token, and the grant behind it is gone. Removing the member runs a preflight first. A personal connection that a toolbox entry depends on has to be transferred or deleted before the removal goes through.
What does Elaichi not control inside Cursor?
Two things: prompt injection, and any MCP server a developer runs outside Elaichi. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. By the time a call reaches the endpoint, the model has already decided what to call. What Elaichi gives you is containment. A manipulated model still cannot call a tool its developer was never granted, and every call it ran is attributable afterwards.
Elaichi governs only the calls that go through its endpoint. A local server a developer adds to mcp.json beside it, such as one started with npx, runs on the laptop and never touches Elaichi. On Cursor Enterprise, the allowlist is the control for those.
When is a per-developer mcp.json still enough?
When three developers share one read-only account and nobody is asking who called what. A prototype against a public API needs no OAuth app and no log. Keep each app's own server in the file, keep any secrets in a password manager, and revisit when a contractor joins or someone asks for a record. Check the signals that you need a gateway before you buy one.
Cost is the other honest constraint. Gold lists at $15 per user per month in USD, and the pricing page shows the price for your region. Gold starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two.
The same address serves the rest of the company: the Claude setup and the ChatGPT setup use it unchanged. If a developer's sign-in fails, start with what each OAuth error means. For a rollout with Jira and Slack, read how to roll out Cursor to an engineering team, or browse the connector catalog.
