Cursor

coord login finds Cursor on its own, registers Coordigent in ~/.cursor/mcp.json and adds the hooks that report edits and deliver messages, in every repo. A rule Cursor applies to every agent comes with the repo files.

Set it up

Log in once per machine. Each repo also has to be connected once, by anyone in the project: say yes when its first agent asks, or run coord connect in it. Until then nothing done there is recorded.

$ coord login

$ coord connect # once per repo, inside it, unless a teammate connected it already

coord login (and coord connect, which does the same) detects Cursor when ~/.cursor exists, or cursor or cursor-agent is on your PATH, or agent is on your PATH and belongs to a Cursor CLI install, and wires it at user level.

To also write Cursor's files into a repo, for a team that commits them, run coord connect --repo-files inside it. That writes them when the repo already has a .cursor/ directory, or when you say yes to its one question about the other agent apps on this machine. To name Cursor without the question:

$ coord connect --repo-files --clients cursor

Restart Cursor if it was open, so it loads the new server.

What gets written

On this machine

One entry in ~/.cursor/mcp.json, named coordigent:

{
  "mcpServers": {
    "coordigent": {
      "type": "stdio",
      "command": "/Users/you/.tower/bin/coord-mcp",
      "args": [],
      "env": {}
    }
  }
}

The path is absolute because desktop apps start MCP servers with a short PATH. Other servers in the file stay. An existing coordigent entry is kept, unless its command points at a binary that no longer exists. An old tower entry that runs tower-mcp is deleted in the same write. No token is stored here: coord-mcp reads your login from ~/.tower/config.json.

~/.cursor/hooks.json gets the same hooks as a repo's .cursor/hooks.json, below. Hooks you added yourself are kept.

In the repo, with --repo-files

.cursor/mcp.json: the same coordigent server, found through $HOME so the file is identical on every teammate's machine, with the repo named in COORDIGENT_REPO.
.cursor/rules/coordigent.mdc: the coordination rules, with alwaysApply: true so Cursor loads them for every agent in the repo.
.cursor/hooks.json: hooks for agent start and end, prompts, file reads and edits, and shell commands, plus postToolUse, which delivers waiting messages. Hooks you added yourself are kept.

coord connect --repo-files also writes Claude Code's repo files; see Claude Code.

Only for Cursor

coord install cursor writes Cursor's repo MCP entry and rule without the rest of coord connect. It also prints a cursor:// install link, if you would rather let Cursor add the server itself. With --user it writes ~/.cursor/mcp.json instead. Cursor's user rules live in a settings screen rather than a file, so at that scope the rules are printed for you to paste into Cursor > Customize > Rules > User Rules.

$ coord install cursor --user

Update

$ coord update

This downloads the current coord and coord-mcp and restarts the daemon. Restart Cursor to load the new coord-mcp.

Check it

$ coord doctor

coord doctor lists cursor with a ✓ and the config file it found, and a Hooks: line naming the events whose hooks are installed, or none. A ✗ line names the command that fixes it. In Cursor, open Customize > MCP and check that coordigent is listed, then ask the agent to call coordigent.status. Cursor asks you to approve a server from a repo's .cursor/mcp.json the first time it sees it.

What works and what degrades

Cursor supports MCP resources, prompts, elicitation and roots. Sampling, resource subscriptions and server notifications stay off. Coordigent does not need them.

Files in use and conflicts. The hooks record each edit, so other agents see what a Cursor agent holds.
One agent per chat. Cursor shares one Coordigent connection across a window's chats. When a window has one chat open, Cursor starts the connection in that workspace, and no other window has the same folder open, its tool calls and its edits show as one agent. Otherwise — two chats in the window, two windows on one folder, or a connection Cursor starts in your home folder — each chat's edits show as its own agent and the tool calls as another, rather than guessing which chat made them. Because the connection is shared, a chat that reads messages with coordigent.message.inbox reads them for the whole window: the other chat will not see them again. Messages sent to a chat itself arrive through its own hook either way.
Messages. The postToolUse hook delivers messages and conflict warnings to a running agent without a restart. They also arrive as a ⚠ COORD: banner on the next coordigent.* tool result, and coordigent.message.inbox reads the rest. An idle Cursor chat runs no hooks, so it hears nothing until someone types. When one has had messages waiting for two minutes, the daemon shows a desktop notification: "Cursor 3f2a · widgets: 2 Coordigent messages waiting. Type anything in that chat to deliver them." It shows at most one every 10 minutes per chat, and none for the chat's own messages. {"desktopNotifications": false} in ~/.tower/preferences.json turns these off, along with the other notifications.

Remove

To remove Coordigent from this machine entirely, run coord uninstall (add --dry-run to see the plan first). It keeps anything you edited by hand.

To remove only Cursor's setup by hand, delete the coordigent entry from ~/.cursor/mcp.json and the repo's .cursor/mcp.json, the Coordigent hooks from ~/.cursor/hooks.json and the repo's .cursor/hooks.json, and .cursor/rules/coordigent.mdc. To stop Coordigent in one repo only, run coord unenroll there.

MCP tools lists every coordigent.* tool the agent can call.
Conflicts explains what a Cursor agent is warned about.

#Set it up

#What gets written

#On this machine

#In the repo, with --repo-files

#Only for Cursor

#Update

#Check it

#What works and what degrades

#Remove

#Next