Concord MCP – shared work‑state for AI coding agents

What it is – An open‑source, local‑first coordination layer that lets multiple AI‑powered coding assistants (Claude Code, Codex, Cursor, Gemini CLI, Grok Build, Goose, GitHub Copilot CLI, etc.) talk to each other while they work on the same codebase. It runs a tiny MCP (Message‑Passing Control Protocol) server backed by a local SQLite DB and provides a set of tools (start_work, inspect_work, update_work, transfer_work, finish_work) plus a friendly CLI.

Why it matters – Without a shared layer, each assistant works in isolation, leading to duplicated edits, hidden conflicts, and lost context. Concord gives agents a common “workspace” where they can claim files, detect overlaps before editing, exchange prompts/replies, hand off tasks, and attach evidence for later review.

---

Quick start (from the README)

# install the global CLI package
npm install -g @concord-ai/concord-mcp

# go to a repository you want the agents to share
cd /path/to/your/repo

# set up the local Concord workspace and register the MCP server
concord setup

concord setup creates a hidden .concord/ directory, writes the MCP configuration files for each supported agent, and (optionally) installs the small “adapter” binaries that let those agents reach the server. It can be re‑run safely and also supports a global mode that registers Concord for any repository a user works on.

---

Core concepts & tools

Tool	What it does
start_work	Agent announces its presence, claims a file/module, and gets warned about existing claims.
inspect_work	Reads the current workspace state, lists present agents, shows stale claims, or fetches a durable prompt/reply thread.
update_work	Sends a prompt to another agent or replies to a pending message.
transfer_work	Offers, accepts, declines, or re‑assigns a task – the basis for hand‑offs.
finish_work	Marks a task complete, attaches evidence (e.g., HANDOFF.md, REVIEW_PACKET.md).

All operations are version‑guarded: concurrent updates on the same task version are serialized, and every change is stored in an append‑only audit log.

---

Supported agents (as of the README)

• Claude Code
• Codex
• Cursor
• Gemini CLI
• Grok Build
• Goose
• Google Antigravity
• GitHub Copilot CLI
• Any other MCP‑capable coding assistant (via the generic MCP tools)

Each agent has a short integration guide (e.g., docs/claude-code.md) that explains how the Concord adapters inject the necessary instruction files into the agent’s config.

---

Typical workflow

1. Setup – Run concord setup in the repo (or globally). The .concord/ folder now holds concord.db (the SQLite source of truth) and a few human‑readable artifacts.
2. Claim – Agent A calls start_work to claim src/app/page.tsx. Concord records the claim.
3. Detect overlap – Agent B also wants the same file; its start_work call returns an overlap warning.
4. Negotiate – Agent B uses update_work with operation: "prompt" to ask Agent A to take a different module. Agent A replies via update_work with operation: "reply".
5. Hand‑off – Once the division of labor is settled, transfer_work is used to formally assign the new module to Agent B.
6. Finish – After the work is done, finish_work stores a REVIEW_PACKET.md and marks the task closed.
7. Inspect – Humans can run concord dashboard or concord status to see who is working on what, any stale claims, and ready‑for‑review packets.

---

CLI snapshot (selected commands)

concord status               # overview of agents, tasks, overlaps
concord dashboard            # live TUI view of activity
concord who                  # list present agents and their current claims
concord tasks                # enumerate all tracked tasks
concord handoff <task-id>    # show the latest hand‑off document
concord review-packet <id>    # show the review packet for a task
concord check <files...>     # exit 1 if any listed file is claimed by another active task (useful in CI hooks)
concord adapters status      # shows which agents have reachable adapters installed

The CLI mirrors the MCP tools, so scripts or other agents can call the same operations via HTTP/JSON or directly through the Node package.

---

Persistence & workspace layout

.concord/
├─ .gitignore          # catches everything, keeping the workspace local
├─ concord.db          # SQLite DB – the single source of truth
├─ HANDOFF.md         # human‑readable hand‑off summary for the last transfer
├─ REVIEW_PACKET.md   # evidence package ready for a reviewer
├─ events.jsonl       # chronological log of tool events (one JSON per line)
└─ WORK_STATE.json    # exported snapshot of the current work state

The DB lives at the repository root (or in a global location for “global mode”). Linked Git worktrees share the same DB, ensuring consistent coordination across multiple checkouts.

---

Telemetry & privacy

Concord sends anonymous usage telemetry to getconcord.ai (install IDs, version numbers, operation names, latencies, etc.) but never transmits source code, file paths, raw messages, or personal identifiers. Telemetry can be disabled with CONCORD_TELEMETRY_DISABLED=1 or DO_NOT_TRACK=1.

---

What it is not

• Not an autonomous coding agent or orchestrator.
• Not a hosted sync service; everything runs locally.
• Not a vector‑store or memory DB for LLMs.
• Not a replacement for code review tools – it only packages evidence for a downstream reviewer.

---

License

MIT (see LICENSE).

---

Bottom line – Concord MCP is a lightweight, locally‑hosted coordination server that gives multiple AI coding assistants a shared, conflict‑aware workspace. It lets agents claim work, detect overlaps, exchange prompts, and hand off tasks without a human acting as a go‑between, while keeping a durable, queryable record of what happened.