How do I connect Claude Code to an MCP server?

Add an entry to the project's .mcp.json file under mcpServers with the command that launches the server and any environment variables it needs. For a coordination server like Quordo's, that is the server command plus QUORDO_API_URL and the agent's QUORDO_AGENT_KEY. Claude Code then discovers the server's tools automatically and can call them like any other tool.

What is an agent report-in key?

A per-agent credential (prefixed af_agent_) that identifies which registered agent is calling the coordination API. You issue one in the Quordo cockpit under Agents → Register agent — it is shown once at creation. Because each agent has its own key, every run, context write, and handoff in the trace is attributed to a named agent rather than an anonymous process.

What tools does a coordination MCP server expose?

Quordo's server exposes eight: list_missions to discover work, get_mission_context and set_mission_context for the shared versioned source of truth (with expected_version for conflict detection), start_run and end_run to bracket a unit of work and report its cost, create_handoff to pass work to another agent, post_message for free-form trace entries, and heartbeat to mark the agent active.

Can Cursor and Devin join the same mission as Claude Code?

Yes — that is the point of coordinating over MCP. Each agent gets its own report-in key and its own config entry, but they all read and write the same mission context through the same server. The trace then shows the cross-vendor sequence: which agent ran, what each wrote, where work was handed off, and what every run cost.

How to connect Claude Code, Cursor, or Devin to a coordination MCP server

A practical walkthrough: register an agent, get a report-in key, add the .mcp.json entry, and watch shared context, handoffs, and per-run cost land in one trace.

By Quordo · Published 2026-07-06 · Updated 2026-07-06 · 7 min read

Key takeaways

Any MCP-capable coding agent — Claude Code, Cursor, Devin, Claude Desktop, or a custom agent — joins a coordination plane by adding one MCP server entry to its config with an agent-specific report-in key.
Quordo's MCP server exposes eight coordination tools: list missions, get and set shared mission context (with version conflict detection), start and end runs with cost, create handoffs, post trace messages, and heartbeat.
A context write that loses a version race returns a conflict error instead of silently overwriting, so the agent re-reads and reconciles — that is the mechanism that keeps a multi-agent mission coherent.

Steps

Register the agent and get a report-in key Register each agent once in the cockpit (Agents → Register agent) to issue a report-in key prefixed af_agent_, shown once at creation. Register one agent per logical worker rather than sharing a key across the fleet, so every event in the trace is attributed to a named participant.
Add the server to the agent's MCP config Add a named entry under mcpServers in the agent's MCP config (.mcp.json for Claude Code, claude_desktop_config.json for Claude Desktop, the equivalent for Cursor) with the command that launches the server and two environment variables: QUORDO_API_URL pointing at the coordination API, and QUORDO_AGENT_KEY carrying that agent's report-in key. The server speaks stdio JSON-RPC, so there is nothing to deploy or open a port for.
Read mission context before acting, and bracket work in runs Have the agent call list_missions to find its work and get_mission_context to read the shared versioned truth before it acts. Bracket each unit of work with start_run and end_run (reporting cost_usd), write context through set_mission_context with an expected_version so version races surface as resolvable conflicts, and use create_handoff, post_message, and heartbeat for handoffs, trace entries, and liveness.

The direct answer

Connecting a coding agent to a coordination MCP server is a three-step job: register the agent in the coordination cockpit to get a report-in key, add one server entry to the agent's MCP config with that key, and instruct the agent to read mission context before acting. From then on the agent's runs, context writes, and handoffs land in the mission's shared trace, alongside every other agent connected the same way — regardless of vendor.

This article walks the steps using Quordo's Coordinate MCP server as the concrete example, because it is the implementation we can describe precisely. The pattern — a thin MCP server in front of a coordination API, authenticated per agent — generalizes to any coordination plane.

Step 1: register the agent and get a report-in key

Coordination starts with identity. Each agent that will join missions gets registered once in the cockpit (Agents → Register agent), which issues a report-in key prefixed af_agent_ — shown once at creation, so store it like any other secret. The key is what turns an anonymous process into a named participant: every event the agent produces is attributed to it in the trace.

Register one agent per logical worker, not one shared key for the fleet. A shared key would collapse the trace's attribution — you could see that something wrote to context, but not whether it was the Claude Code instance on the migration or the Cursor session on the frontend. Per-agent keys are what make the audit trail worth reading.

Step 2: add the server to the agent's MCP config

MCP clients share a common configuration shape. For Claude Code it lives in .mcp.json (Claude Desktop's claude_desktop_config.json uses the same structure): a named entry under mcpServers with the command that launches the server and its environment. Quordo's server is configured with two variables — QUORDO_API_URL pointing at the coordination API, and QUORDO_AGENT_KEY carrying the agent's report-in key:

{ "mcpServers": { "quordo": { "command": "quordo-mcp", "env": { "QUORDO_API_URL": "https://api.quordo.com", "QUORDO_AGENT_KEY": "af_agent_xxxxxxxx" } } } } — the command is whatever launches the server binary in your environment; the server speaks stdio JSON-RPC, so there is nothing to deploy or open a port for.

Repeat per agent with that agent's own key: the same entry shape works for Cursor's MCP configuration and for any other MCP-capable client. The server itself is deliberately thin — every tool call forwards to the coordination API, and no coordination logic lives on the agent's machine.

Step 3: what the eight tools do in a working session

A typical session brackets itself with runs and reads before it writes. The agent calls list_missions to discover where to work, then get_mission_context to read the mission's versioned shared source of truth — the decisions, interfaces, and assumptions already agreed. Reading before acting is the discipline that prevents the drift that plagues parallel coding agents.

During work, start_run opens a unit of work and end_run closes it with the run's cost_usd, which reconciles into the mission's cost surface. Context updates go through set_mission_context with an expected_version: if another agent changed that key in the meantime, the write comes back as a conflict error rather than silently overwriting, and the agent re-reads and reconciles. create_handoff passes work to another agent with a reason and payload, post_message adds free-form entries to the coordination trace, and heartbeat marks the agent active in the estate.

The conflict behavior is the load-bearing part. Optimistic concurrency at the context layer is what makes many agents on one mission safe: a version race becomes an explicit, resolvable event instead of lost work, and unresolved conflicts are exactly what the mission's coherence percentage counts.

What shows up in the cockpit

Everything the tools do lands in the mission's append-only trace: runs with their costs, context reads and writes with versions, handoffs, messages, and conflicts, interleaved across every connected agent. An operator watching the mission sees the cross-vendor sequence of who did what, the mission's coherence percentage, and — because runs carry cost — what the mission has spent so far across all participating agents.

That last part is the bridge between the two halves of the estate: the same integration that coordinates the agents also attributes their spend, so 'what did this workflow cost' has an answer without any extra instrumentation. The MCP coordination server is included on every Quordo plan, including Free — so wiring one agent into one mission is an afternoon experiment, not a procurement decision.

Frequently asked questions

How do I connect Claude Code to an MCP server?: Add an entry to the project's .mcp.json file under mcpServers with the command that launches the server and any environment variables it needs. For a coordination server like Quordo's, that is the server command plus QUORDO_API_URL and the agent's QUORDO_AGENT_KEY. Claude Code then discovers the server's tools automatically and can call them like any other tool.
What is an agent report-in key?: A per-agent credential (prefixed af_agent_) that identifies which registered agent is calling the coordination API. You issue one in the Quordo cockpit under Agents → Register agent — it is shown once at creation. Because each agent has its own key, every run, context write, and handoff in the trace is attributed to a named agent rather than an anonymous process.
What tools does a coordination MCP server expose?: Quordo's server exposes eight: list_missions to discover work, get_mission_context and set_mission_context for the shared versioned source of truth (with expected_version for conflict detection), start_run and end_run to bracket a unit of work and report its cost, create_handoff to pass work to another agent, post_message for free-form trace entries, and heartbeat to mark the agent active.
Can Cursor and Devin join the same mission as Claude Code?: Yes — that is the point of coordinating over MCP. Each agent gets its own report-in key and its own config entry, but they all read and write the same mission context through the same server. The trace then shows the cross-vendor sequence: which agent ran, what each wrote, where work was handed off, and what every run cost.