Is there an MCP server that orchestrates Claude Code?

The literal answer

KanBots ships an MCP server as part of the open-source desktop. The binary is called kanbots-mcp-server and lives in the @kanbots/mcp workspace package. It is a stdio process — the standard MCP transport — that translates MCP tool calls into HTTP requests against a local tool bridge running inside the desktop application. Any MCP client that knows how to spawn a stdio server can drive KanBots: Claude Desktop, Cursor, the Claude Code CLI itself, Continue, Cline, or anything custom you write.

The point is not just “another integration.” The point is that you can sit in Claude Desktop and say “dispatch agents on every Backlog card with the engineer persona at parallelism 2, with a $5 cap each,” and Claude will translate that English into the right sequence of MCP tool calls, which the server forwards into KanBots, which dispatches the agents. Claude Desktop becomes the natural-language driver for your kanban. The kanban becomes the workflow primitive that Claude has hands on.

How the wiring fits together

Three processes, two transports:

┌────────────────┐  stdio (MCP)  ┌──────────────────────┐  HTTP    ┌──────────────────────┐
│ MCP client     │ ────────────► │ kanbots-mcp-server   │ ───────► │ KanBots desktop      │
│ (Claude        │ ◄──────────── │ (stdio bridge)       │ ◄─────── │ tool bridge          │
│  Desktop /     │               │                      │          │ (127.0.0.1:<port>)   │
│  Cursor / etc) │               │                      │          │                      │
└────────────────┘               └──────────────────────┘          └──────────────────────┘

The client speaks the MCP protocol over stdin/stdout. The MCP server forwards each tool call to http://127.0.0.1:<port> — an HTTP endpoint that the running KanBots desktop application exposes only on localhost, never on the LAN. Two environment variables tie it together:

• KANBOTS_TOOL_BRIDGE_URL — the bridge URL printed by the desktop on startup, e.g. http://127.0.0.1:34567.
• KANBOTS_TOOL_BRIDGE_TOKEN — a bearer token regenerated every desktop session. Visible in the desktop under Settings → MCP server, with a Copy config snippet button.

Both values are surfaced in the KanBots Settings UI; you paste them into your MCP client’s config and restart the client. That’s it.

The tools the server exposes

Two categories: issues (the cards on the board) and agent runs (the work happening on them).

Issue CRUD

• listIssues — filter by state: 'open' | 'closed' | 'all'. Returns the cards visible in the active workspace.
• getIssue— full detail for one card: title, body, labels, current column, attached run history.
• createIssue — title, optional body and labels. New card lands in the Inbox column.
• updateIssue— partial patch to title, body, labels.
• moveIssueStatus — number, status (one of the five column keys). In GitHub mode this also updates the status:* label on the underlying GitHub issue.
• archiveIssue— soft-delete; removes the card from the board.
• splitIssue — number plus children: [{ title, body }]. Creates linked subtasks from one parent.

Agent runs

• dispatchAgent — issueNumber, optional model and personaId. Spawns the agent on a fresh worktree at .kanbots/worktrees/issue-N-<runId>/.
• stopAgentRun — runId. Sends SIGTERM, then SIGKILL on grace expiry.
• listAgentRuns— optional filters by issue, status, persona. Useful for “show me what’s still running.”
• listPendingDecisions— every blocked run waiting on a human decision.
• resolvePendingDecision — runId, value. Unblocks the run.

All inputs are validated by JSON Schema declared in packages/mcp/src/index.ts. Outputs are pure JSON — no streaming responses, no opaque blobs. The MCP client gets back structured data it can feed into its own reasoning.

Wiring it into Claude Desktop

Claude Desktop reads MCP server config from a JSON file. The path depends on the OS:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Linux: ~/.config/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Add an entry to the mcpServers object:

{
  "mcpServers": {
    "kanbots": {
      "command": "kanbots-mcp-server",
      "env": {
        "KANBOTS_TOOL_BRIDGE_URL": "http://127.0.0.1:34567",
        "KANBOTS_TOOL_BRIDGE_TOKEN": "kb_live_<paste-from-Settings>"
      }
    }
  }
}

If kanbots-mcp-server is not on your PATH— for example you’re running it from a checked-out monorepo rather than a packaged build — substitute the absolute path:

{
  "mcpServers": {
    "kanbots": {
      "command": "/Users/me/code/kanbots/packages/mcp/dist/server.js",
      "args": [],
      "env": {
        "KANBOTS_TOOL_BRIDGE_URL": "http://127.0.0.1:34567",
        "KANBOTS_TOOL_BRIDGE_TOKEN": "kb_live_..."
      }
    }
  }
}

Restart Claude Desktop. Open a new conversation. Type “list my open KanBots issues” — if the wiring is right, Claude will pick the listIssues tool and return the board.

Wiring it into Cursor

Cursor reads ~/.cursor/mcp.json with the same shape:

{
  "mcpServers": {
    "kanbots": {
      "command": "kanbots-mcp-server",
      "env": {
        "KANBOTS_TOOL_BRIDGE_URL": "http://127.0.0.1:34567",
        "KANBOTS_TOOL_BRIDGE_TOKEN": "kb_live_..."
      }
    }
  }
}

Cursor’s Composer can then call KanBots tools alongside its in-editor ones. A natural pairing: ask Composer to implement a feature in-editor, then ask it to dispatchAgent a reviewer run on the corresponding KanBots card.

Wiring it into Claude Code CLI

Claude Code accepts a --mcp-config flag pointing at a JSON file:

# ~/kanbots-mcp.json
{
  "mcpServers": {
    "kanbots": {
      "command": "kanbots-mcp-server",
      "env": {
        "KANBOTS_TOOL_BRIDGE_URL": "http://127.0.0.1:34567",
        "KANBOTS_TOOL_BRIDGE_TOKEN": "kb_live_..."
      }
    }
  }
}

# in any shell
claude --mcp-config ~/kanbots-mcp.json \
  -p "list open kanbots issues and dispatch the top three with persona=engineer"

This is the “ops automation” entry point. A daily cron job can shell out to claude with this config and a triage prompt; the agent reads the board, decides what to dispatch, and KanBots runs it. The KanBots desktop must be open and signed in for the tool bridge to be reachable.

Two practical use cases

1. Natural-language batch dispatch

In Claude Desktop, type:

Dispatch agents on every Backlog card whose title contains "auth".
Use the engineer persona, model claude-sonnet-4.6, and stop me before
exceeding $5 per run.

Claude calls listIssues filtered to state: 'open', client-side filters by title substring, asks you to confirm the candidate list, then calls dispatchAgent on each approved card. The runs appear in the KanBots board with their usual live thread; you watch them progress in the desktop UI.

2. Daily triage script

Wire a cron job to the Claude Code CLI:

# in crontab
0 9 * * * cd ~/myrepo && claude --mcp-config ~/kanbots-mcp.json -p "$(cat <<'EOF'
Read every Inbox card via kanbots tools. For each one:
- If it looks like a real bug report, move to Backlog with status:bug label.
- If it's already a duplicate of an open issue, archiveIssue it with a note.
- Otherwise leave it in Inbox.
Print a summary of what you did.
EOF
)"

Every morning at 9am, the agent triages the Inbox using the MCP tools. No human is required for the routine part; you only see the summary. Failure modes still go through normal KanBots decision prompts, so if the agent is unsure it pauses the relevant card.

Security notes

The tool bridge is intentionally local-only. Three concrete properties:

• Bound to 127.0.0.1. Not the LAN, not 0.0.0.0. A second machine on your network cannot reach the bridge.
• Token rotated per desktop session.When the desktop restarts, the old token stops working. You copy a fresh snippet from Settings. This means MCP client configs need to be refreshed if you frequently restart the desktop — an intentional cost to keep ambient credentials out of dotfiles.
• Token grants the full bridge surface.Anything KanBots can do (dispatch agents that spend money, edit issues, resolve decisions) the bearer can do. Treat it like a session secret. Don’t paste it into untrusted clients.

For the cloud product, the MCP server has a different shape — token issued via OAuth device flow, bound to your org, scoped by permission. That’s out of scope for this page; this document describes the OSS desktop wiring.

Things to know before you wire this up

• The KanBots desktop must be running. The tool bridge lives inside the Electron process. If you close the app, MCP clients get connection errors. The desktop has no headless mode in OSS.
• Dispatching from MCP uses the same agent CLI you configured in Providers. If your workspace is set to Claude Code, MCP-driven dispatches run Claude Code. If you want a mixed-CLI board driven from MCP, use the personaId argument to pick a persona whose CLI you want.
• Cost caps apply to MCP-driven runs the same way they apply to UI-driven runs.The autopilot session budget is a property of the dispatch, not of how you triggered it. A natural-language batch can’t spend more than your configured caps.
• Promote / open PR are not MCP-exposed. Deliberately. Promoting a worktree to a real branch is a human decision; we don’t let the model do that on your behalf. The MCP surface stops at “the agent ran and produced a result.” You promote in the UI.

Decision rubric

• You want to drive KanBots from Claude Desktop or Cursor: the MCP server is the right path. Wire it once, use it forever.
• You want unattended cron-style automation: MCP server + Claude Code CLI in a shell script. Sleeps when the desktop is closed.
• You want headless team-wide orchestration: that’s KanBots Cloud’s lane, not the OSS MCP server. The bridge is per-desktop; the cloud is per-org.
• You want to expose KanBots to a custom MCP client: any client that speaks stdio MCP works. The tool list is stable; treat it like any other JSON RPC.

Related reading

For the structural argument behind KanBots vs Devin (locality, BYOK), see is there a self-hosted Devin alternative. For the 2026 rubric scoring KanBots, Cursor, Devin, Aider, and Claude Code on the four traits that matter, see what is the best AI coding agent setup in 2026. For the underlying Claude Code vs Codex choice that determines which CLI MCP-driven dispatches actually spawn, see Claude Code vs Codex CLI for parallel agents.