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

> Cursor reads a config file on your machine, which makes scoping a choice the other AI clients do not offer — one entry for everything you work on, or one confined to a single repository.

**TL;DR** Cursor's MCP config is a file, not an account setting. That means setup is per machine rather than per person, and you choose between a global entry in ~/.cursor/mcp.json and a project-scoped one in the repository. The endpoint is the same either way, and so is the access boundary.

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

| Symptom | Usually |
|---|---|
| The server never appears after editing the file | Invalid JSON — a trailing comma or a missing brace. Check it parses, then reload |
| No sign-in prompt appears | Cursor did not reload. Reload the window, then open the MCP settings to trigger it |
| A tool you expect is missing | A restriction blocks it, it is not in a toolbox you can reach, or the 30-tool threshold collapsed the list — ask Cursor to search for it |
| A call is refused after consent | The scope it needed was not granted. Reconnect and widen it |
| It works on one machine and not another | The configuration is per machine. Repeat it there and sign in |

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](/connectors/) has a guide per application; start with whichever system your team's work actually runs through.

## FAQ

### Should I put the Elaichi entry in the global or the project config?

Global, in ~/.cursor/mcp.json, is right when you want your tools available whatever you happen to have open. The project file, .cursor/mcp.json in a repository, is right when only one codebase should be able to reach them — a client project, or a repo where you would rather an agent could not read the CRM. They are not exclusive; a project entry simply applies where it lives.

### I set Cursor up on my laptop. Why does my desktop not have it?

Because the configuration is a file on a machine rather than a setting on your account. Repeat the setup on each computer you use and sign in on each. The upside of the same property is that a machine you no longer use stops having access the moment you stop using it, with nothing to revoke centrally.

### Cursor is not showing the server after I edited mcp.json. What is wrong?

Two causes cover almost all of it. The JSON does not parse — a trailing comma or a missing brace — so check the file is valid. Or Cursor has not reloaded; reload the window and open the MCP settings to trigger the connection. There is no type field and no command to run in this entry, so if you have added either, remove them.

### Does a project-scoped entry mean my teammates get it too if I commit the file?

They get the configuration, not the access. Committing .cursor/mcp.json shares the endpoint address, which is not a secret — it carries no credential. Each teammate still signs in as themselves on first use and gets the tools their own role and shares allow. The file tells Cursor where to look; Elaichi decides what they see.