Connect an MCP client

Connect an MCP client when you want the board’s tools inside your own Claude Code session, or when your agents need a tool from another MCP server. You end with the server listed in Settings and its tools approved once.

Use the board from Claude Code

mcp.json at the repo root registers the board as native MCP tools. Start a session with:

claude --mcp-config mcp.json --strict-mcp-config \
  --allowedTools "mcp__kanban__*,Read,Edit,Bash"

The board must be running for the MCP server to reach it. Every tool it exposes is listed in Kanban MCP tools.

Auth

mcp.json forwards REV0_AUTH_TOKEN to the MCP server through ${REV0_AUTH_TOKEN:-} expansion, so when the board runs with an access token the write tools authenticate as Bearer instead of getting a 401. Export REV0_AUTH_TOKEN=... in the shell you launch claude from; when it is unset the value expands to empty and zero-config local use is unchanged.

Install a server in every engine

Installed in claude, codex and cursor, at the top of Settings > Connections > MCP servers, writes a server into each engine’s own configuration, so it is there for board runs and for the CLIs you open yourself. One row per server, one toggle per engine.

1. Click + Add MCP server in that panel, fill the form as below, leave the engines you want ticked and click Install.
2. To put an existing server on an engine that lacks it, click + codex (or the missing engine) on its row, or Add to missing for all of them. The board copies the entry, headers and environment included, from an engine that has it.
3. To take one off, click its ticked engine, or Remove everywhere, and confirm.

Each engine answers on its own and a failure is named under the row. Codex has no sse transport, so an sse server is skipped there. A server that signs in with OAuth needs a sign-in per engine (the row names the command, like codex mcp login <name>). claude.ai account connectors and plugin servers are read-only here; an account connector links to claude.ai to manage it. Gemini is listed but not written to. REV0_ALLOW_MCP_EDIT=0 hides the panel’s actions.

Give runner agents other MCP servers

1. Open Settings > Connections > MCP servers and click + Add MCP server.
2. Type a name (letters, digits, - and _; kanban and plugin are taken).
3. Pick a transport:
   • stdio (local process) for a process the agent spawns. Paste the whole command in Command and optional environment variables, for example TOKEN="secret value" npx -y @vendor/mcp-server: the form splits it into the variables, the command and its arguments.
   • http (remote URL) or sse (remote URL) for a hosted connector: its URL, and any Headers it needs (an Authorization header for a token).
4. Click Test connection. It connects to that one server and lists the tools it exposes, with the rule that allows them all (mcp__<name>__*). The button waits until the name and the command or URL are filled in.
5. Click Save changes. Install to engines on the row also writes it into each engine’s own configuration (see above).

Result: the next agent run gets the server. A server that fails to start on a Claude run is named on the ticket timeline (“MCP server unavailable this run: …”), rather than the agent quietly getting a shorter tool list.

A vendor’s docs often give the server as JSON. Paste it into Paste JSON from a vendor’s docs and click Add from JSON instead of filling the form.

Operators can also point REV0_MCP_CONFIG at a JSON file in Claude’s mcp.json format ({"mcpServers": {"name": {...}}}); see config/extra_mcp.example.json for the shape. The two sources add up, and a Settings entry wins on a name clash. A server’s command runs on the runner host, so REV0_ALLOW_MCP_EDIT=0 makes the Settings list read-only (it then shows Editing disabled, and Test connection is refused).

Which engines get the list

Engine	What it gets from MCP servers
Claude Code	Every server.
Codex	Every server on the default transport. With REV0_CODEX_TRANSPORT=exec, http and sse servers are dropped.
Cursor	None. Cursor reads only its own configuration (~/.cursor/mcp.json); use Install to engines on the row, or install it in every engine.

Approve the tools once

On a Claude run the tools are not auto-approved: the first call routes through the approve or decline panel (Approve a tool request), so wiring a server up never silently grants a new capability. Click Always allow all of that server’s tools there, or add mcp__<name>__* under Settings > Security > Tool & MCP permissions, to stop it asking.

Other engines do not ask. Codex runs a board server’s tools without a prompt, and a deny rule only holds on Codex when it covers the whole server (mcp__<name>__*, which then withholds the server); a rule for one tool is not enforced there, and the ticket says so. Cursor runs skip the board’s approvals altogether.

See what each engine already has

Besides the board’s list, each engine loads servers from its own configuration on this host. Under Settings > Connections > MCP servers, Managed by each engine shows them, one tab per engine, with a health dot and the server’s scope, transport and status. Click Refresh to read them again.

To keep one of them away from agents, untick Available to agent runs on its row and save: that adds a deny rule for mcp__<name>__* under Tool & MCP permissions. Your own sessions in that CLI are untouched. The block holds on Claude runs; a server that Codex reads from its own ~/.codex/config.toml is not withheld by it.

Result: you know which servers a ticket on each engine can reach, and the ones you do not want are blocked.

When a tool works in Claude Code but not for the agent

Check which engine the ticket ran on first, because they do not see the same set.

A Claude run is not sealed off: the runner passes setting_sources=["user","project"], so the headless CLI also mounts your ~/.claude.json servers and the OAuth account connectors (Atlassian, Notion, Slack, …). A Codex run cannot see any of that; it reads its own ~/.codex/config.toml. A Cursor run reads Cursor’s configuration only. So the same board, settings and ticket can have Atlassian on one engine and not another; Managed by each engine shows the difference instead of leaving you to guess.

To make a tool available to Claude and Codex alike, add it as a board entry rather than relying on what a host happens to have: use the vendor’s remote MCP endpoint (http or sse) with its own token instead of the in-app connector.

{
  "mcpServers": {
    "atlassian": {
      "type": "sse",
      "url": "https://<atlassian-remote-mcp-endpoint>",
      "headers": { "Authorization": "Bearer <token>" }
    }
  }
}

Paste exactly that into Paste JSON from a vendor’s docs, with the endpoint and auth from the vendor’s remote MCP server docs. Tick Board list only. to stop Claude runs mounting the servers from your own Claude configuration, so they get exactly the board’s list; Codex still reads its own config.toml and Cursor its own configuration.

Note

A connector behind OAuth needs a login on the runner host, which no board setting can do for you: a url with no credentials connects as anonymous. Run claude mcp add --transport sse <name> <url> then /mcp to authenticate for Claude, or codex mcp add --url <url> <name> then codex mcp login <name> for Codex. codex mcp list --json reports "auth_status" per server, which is how you tell “configured” from “logged in”.

Related

• Kanban MCP tools, for every tool the board gives an agent.
• Approve a tool request, to answer the first call to a new server.
• Permission lists, to allow or deny a server for good.
• Run Codex or Cursor, for what else differs between engines.