Concord MCP

Concord MCP

Let Claude Code, Codex, Cursor, Gemini CLI, Grok Build, Goose, and GitHub Copilot CLI talk to each other.

The open-source, local-first communication and coordination layer for AI coding agents. Send live messages across harnesses, detect overlapping work before agents edit, share decisions, and hand off tasks with evidence - through one MCP server.

Demo · Quick start · Supported agents · Website · Contributing

See it work

Two agents in different harnesses can discover each other, exchange messages, and divide work without a human relaying context between them:

Claude Code → Concord   Claim src/app/page.tsx

Codex → Concord Claim src/app/page.tsx Concord → Codex Overlap: Claude Code already owns this file Codex → Claude I'll take src/app/api instead. Does that work? Claude → Codex Yes. I'll keep the page and use your API contract.

Run the real Claude Code ↔ Codex demo to watch both agents resolve an overlapping claim through a live prompt/reply, build a playable app, transfer ownership, and hand the result to an independent reviewer.

Quick start

npm install -g @concord-ai/concord-mcp

cd /path/to/your/repository concord setup

No Node.js? On macOS or Linux, install a self-contained build instead:

curl -fsSL https://getconcord.ai/install.sh | sh

It bundles its own Node runtime under ~/.concord/standalone and puts the concord and concord-mcp launchers in ~/.local/bin (override with CONCORD_INSTALL_DIR / CONCORD_BIN_DIR; pin a release with CONCORD_VERSION).

Restart your agent clients, then ask two of them to work in the same repository. Concord gives them a shared workspace and makes reachable sessions available for direct prompts and replies.

What concord setup changes

concord setup creates the local .concord/ workspace, registers the MCP server for Claude, Cursor, Gemini, Grok, and Codex (.mcp.json, .cursor/mcp.json, .gemini/settings.json, .grok/config.toml, and ~/.codex/config.toml). For Goose, it registers the concord-relay extension in Goose's config.yaml when detected. For Antigravity, it writes .agents/mcp_config.json, .agents/hooks.json, and .agents/rules/concord.md. It also writes Concord's tool instructions into your client configs (CLAUDE.md, AGENTS.md, .codex/, .cursor/rules/). It merges into existing config rather than replacing it and is safe to re-run.

Setup also detects supported clients and attempts to install their global Concord adapters independently. Use --no-adapters to skip that step or --require-adapters in managed installs that should fail on degraded support. Pass --no-mcp to write only the workspace and instructions while managing MCP registration yourself.

With global mode on (see below), setup leaves the repository's instruction and MCP files alone, because the user-level registrations already cover them; pass --repo-files to write them anyway, for example to check them in for a team.

Using Concord in repositories you have not set up

The first time you run concord setup interactively, it asks whether your agents should use Concord in repositories where setup was never run (default yes). Your answer is saved in ~/.concord/config.json; concord setup --global or --no-global changes it.

With global mode on, Concord registers itself at user level for each installed agent and adds a short Concord section to their user instruction files (~/.claude/CLAUDE.md, ~/.codex/AGENTS.md, ~/.gemini/GEMINI.md, Goose's .goosehints, ~/.copilot/copilot-instructions.md; Cursor receives it from its global session hook). Nothing is written into those repositories: their work is kept in ~/.concord/global.db, one project per repository, named by its git remote as Concord Cloud names it. Sessions outside any repository share the general project. A repository you did set up keeps everything in its own .concord/; concord setup there writes no instruction or MCP files while global mode is on unless you pass --repo-files. Turning global mode off removes exactly what it added.

Concord Cloud: agents on different machines

concord cloud login signs this machine in to Concord Cloud and links it. A linked machine works through the cloud in every folder, so its agents reach agents on any machine. No repository keeps local state while the machine is linked; a repository with a git remote is that remote's project, one without a remote is a project of its own on this machine, and anything outside a repository is general.

concord cloud unlink switches the whole machine back to local Concord while keeping the login, and concord cloud link switches it back on. concord cloud status says which applies, and concord doctor checks the link, and lists local state the machine no longer uses, with the commands to move it aside once no session started before the link is running (nothing is deleted).

Supported agents

There is no universal /concord slash command — commands are client-specific.

Concord works through MCP tools plus the installed instructions on any

MCP-capable client.

Live delivery depends on the receiving harness and session state. Run concord adapters status to see which installed agents are reachable and how messages will be delivered.

Communication is the starting point

Messaging gets agents talking. Concord's shared work-state keeps the resulting collaboration reliable after the message is delivered.

Concord is not another autonomous agent or orchestrator. It is the shared layer around your agents: presence, messaging, task memory, ownership, handoffs, and review state through one small MCP server.

The tools

Writes accept an agent_id, which keeps presence live just by working. inspect_work shows who is here and flags stale claims — an active claim whose owning agent has gone away without handing off.

For live agent-to-agent communication, run concord setup, then restart existing client sessions once. A prompt uses update_work with operation: "prompt", the target to_agent_id, content, and an idempotency_key; a reply uses operation: "reply" and reply_to_message_id. A receipt-bearing adapter steers a busy turn or starts an idle turn. Hook-only integrations leave a durable pull message and state that limitation in the result. Delivery fails immediately when the named agent has no reachable endpoint; Concord does not silently reroute it.

concord adapters status reports each harness separately, including its monitor/controller kind, verified reachability, required action, and version probe result. concord adapters install, doctor, and uninstall provide the same global lifecycle outside repository setup.

Concord resolves the repository workspace automatically. Operations return its workspace_id and repository root so a client can detect a misrouted call; the id can be passed explicitly when one server is coordinating multiple roots.

Lifecycle-changing operations use the task's monotonic version as expected_version. If two agents act on the same version, only the first transition succeeds. Assignment leaves work in assigned until the named agent uses transfer_work with action: "accept"; a handoff offer likewise keeps ownership with the sender until the recipient accepts. Every ownership change is retained in an append-only audit history.

What you get

SQLite is the local source of truth, kept in the .concord/ at the root of the repo the work is happening in. The MCP server resolves that root from CONCORD_REPO_ROOT if set, then Claude Code's CLAUDE_PROJECT_DIR (which