Concord MCP

What the Concord MCP MCP server does

Concord MCP MCP server provides a shared coordination layer for coding agents that operate in different client harnesses. It stores work state locally in a SQLite database under the repository’s .concord/ directory. Agents can register their presence, claim work, exchange messages, record decisions, transfer ownership, and submit evidence for review without relying on a human to relay context.

The system is intended for multiple agents working on one repository. It is not an autonomous agent or an orchestrator. Instead, it gives existing agents a common view of tasks, ownership, messages, handoffs, and review status. Claims can cover files or modules, allowing an agent to identify overlapping work before making edits.

How it works

The server resolves the repository workspace from CONCORD_REPO_ROOT, then Claude Code’s CLAUDE_PROJECT_DIR, and finally its current working directory. Linked Git worktrees use Git’s shared commondir metadata, so linked checkouts and the primary checkout use the same Concord database.

Five MCP tools expose the coordination workflow. start_work registers presence and begins or accepts a task while reporting scope conflicts. inspect_work reads workspace and task state, inbox or outbox messages, and durable prompt/reply threads. update_work records context or sends a prompt or reply. transfer_work manages assignments, acceptance, declines, releases, reassignments, handoff offers, and reopened work. finish_work records evidence and can move a task to review-ready, complete, or closed status.

Writes include an agent_id, which keeps presence current. Task lifecycle changes use an expected monotonic version, so only the first operation against a given version succeeds. Ownership changes remain in an append-only audit history, and stale claims are reported when an agent disappears without handing off its work.

Setup and configuration

Install the package globally with npm, change to the repository, and run concord setup. Setup creates .concord/, registers the MCP server for supported clients, and adds Concord instructions to relevant client configuration files. It merges with existing configuration and can be run again.

The setup process can also attempt to install global adapters for detected clients. Use --no-adapters to skip adapter installation, --require-adapters when degraded support should cause a managed installation to fail, or --no-mcp when MCP registration will be handled separately. Set CONCORD_REPO_ROOT when the server runs outside the repository it should coordinate.

Tools and capabilities

The Concord MCP MCP server supports direct prompts and replies between reachable workspace agents. A prompt identifies the recipient with to_agent_id and includes an idempotency key; replies refer to the original message. Adapter status reports reachability, monitor or controller type, required action, and version probe results. The concord adapters status, install, doctor, and uninstall commands manage adapters outside repository setup.

Delivery behavior depends on the receiving harness and its session state. A receipt-bearing adapter can steer a busy turn or start an idle one. Hook-only integrations leave a durable message for later retrieval. If the named agent has no reachable endpoint, delivery fails rather than being silently redirected.

Limitations and notes

Live delivery requires setup, restarted client sessions, and a reachable receiving harness. Other MCP-capable coding agents can use the shared work-state tools, but their live delivery behavior depends on their integration. There is no universal Concord slash command; clients use MCP tools and installed instructions instead.

The local SQLite database is the source of truth and is stored at the repository root. Operations return the workspace identifier and repository root so clients can detect a misrouted operation. An explicit workspace identifier can be supplied when one server coordinates multiple repository roots. Assignments remain assigned until the named agent accepts them, and handoff offers remain with the sender until acceptance.