Connect your company's apps to Cursor, per machine or per repository

Cursor is the odd one out among AI clients, and it is odd in a way that happens to be useful.

Claude and ChatGPT store your MCP connections against your account, so setting one up once follows you to any machine you sign in on. Cursor reads a file on disk. That sounds like a downside and mostly is — you will do the setup more than once — but it buys a kind of scoping the others simply do not offer, which is worth knowing before you pick where to put it.

One entry, and everything behind it

The shape first, because it is what makes this worth doing at all.

Cursor connects to one endpoint: Elaichi. Your applications are connected inside Elaichi, not inside Cursor. You never add Jira or Linear or the CRM to Cursor — they arrive through the single entry you are about to write.

Because the calls travel through Elaichi rather than around it:

• Access follows the person, resolved on each request against their role and shares.
• A restricted tool is never advertised, so it is not something a prompt can reach.
• Every call is recorded in an append-only log, down to the identifier of the record it changed.
• Disconnecting an application in Elaichi removes it from Cursor, with no file to re-edit.

The alternative — a separate MCP server per application, each with its own URL and its own credential, on each developer's machine — is the thing this replaces.

Global, or one repository

Here is the choice Cursor gives you and the others do not.

~/.cursor/mcp.json applies everywhere on that machine. Open any project and your tools are there. This is the right default for most people: the whole point is that an agent can reach the ticket tracker and the docs while you are working, whatever you happen to have open.

.cursor/mcp.json inside a repository applies to that project only. This is the one to reach for when the blast radius matters — a client codebase, an open-source repo you contribute to, or simply a project where you would rather an agent working on the code could not also read the CRM. It is a real narrowing, and it is enforced by Cursor before a request is ever made.

Committing the project file to the repository is fine. It carries the endpoint address and no credential, so it is configuration rather than a secret. Teammates who pull it still sign in as themselves and still get only the tools their own access allows — the file says where to look, Elaichi decides what they see.

Writing the entry

You will need your endpoint, which lives behind Connect your AI client in the Elaichi web app.

Open ~/.cursor/mcp.json, or .cursor/mcp.json for a single project, and add the endpoint as a url entry under mcpServers. If the file already has other servers there, add yours alongside them rather than replacing the block — the most common way to lose a working setup is to paste over the whole object.

Then reload Cursor, and sign in and approve when it prompts.

There is no type field and no command to run. Cursor detects the transport from the endpoint itself, and because the endpoint supports dynamic client registration there is no auth block, no client ID and no secret to add. If you have seen examples elsewhere that include a transport type, leave it out — an entry here is a name and a URL, nothing more.

The consent screen

Reloading brings up Elaichi's sign-in, then a consent screen, and it is worth reading rather than clicking through.

When you work in the Elaichi web app, permission is asked for at the point of the write. That option disappears over MCP, where nothing between you and the model can be trusted to have actually asked. Consent moves to the front instead, so whatever you tick here stands for every call afterwards.

Four scopes, with only Read granted by default:

• Read — everything you can already see, including admin records like the audit log. Never secret values.
• Create and change — teams, roles, tool sets, connections, organization settings.
• Delete — permanent, reaches inside connected applications, not reversible.
• Run tools — run tools from the toolboxes you select on that screen.

Read and Run tools covers ordinary development work. If you are scoping to a single repository because the project is sensitive, this is the screen where that intent should show up too — granting Delete to an agent working in a client codebase is not a decision to make by reflex.

What Cursor sees

Your access, not the organization's. What you signed in as decides what resolves, exactly as it does in the web app — which is why two developers on the same team, with byte-identical mcp.json files, do not see the same tools.

One behaviour to expect. Past 30 advertised tools — Elaichi's own catalog operations counted together with your connected ones — individual tool names give way to search_tools and execute_tool. The catalog nearly reaches 30 by itself, so one connected application usually crosses the line. It is automatic rather than configurable.

From then on Cursor finds tools by searching, and that search is lexical, not semantic. "create branch", "list issues", "update ticket" retrieve well. A sentence describing your intent does not.

Common failures, and what they mean

To disconnect, remove the entry from mcp.json and reload, or revoke the grant in Elaichi. Revoking is the stronger of the two, and the one to use when a machine is being retired or someone is leaving — it stops the token working immediately rather than depending on a file being edited.

With the endpoint in place, the question becomes which tools belong in a developer's toolbox and which do not. The connector catalog has a guide per application; start with whichever system your team's work actually runs through.