MCP Server Shipped

File and scope work without leaving the session

Your agent can look up the zone map, drop a request into Triage, draft the four fields and read the board — all from inside the conversation it is already having. What no tool here can do is open a zone or approve an access request; a transition is a question put to the gate, never a power the tool holds.

Connect it

cycle mcp    # serves the tools over stdio, for a client's .mcp.json

It ships inside the CLI binary rather than as a second install, so there is one implementation and not two that drift. The Claude Code plugin wires it up for you.

The five tools

ToolWhat it does
cc_zonesThe zone map as the board holds it — paths, risk, owners
cc_intakeOne line into Triage. It does not start anything
cc_interviewDraft the four fields, reconciled against the real zone map
cc_scopeSave those four answers onto the task
cc_statusA single task, or everything in flight. Read-only

Four more on the connector

The board issues a per-machine HTTP connector, and it adds cc_setup,cc_start, cc_submit and cc_close. Each transition is a question the gate answers by the same rules the console obeys — a client of the gate, never a second door. The reference keeps the two surfaces side by side.

The line they do not cross

There is no grant and no resolve. No tool on either server issues a grant, approves access, or decides a transition — cc_start asks, the gate answers — and that absence is as much of the contract as what is present.

The reason is not caution, it is arithmetic. An approval arriving through a tool the agent calls is authenticated by a token the agent holds, so a board could not tell your yes from the agent's own. A gate an agent can call is not a gate. The tools ask; the gate decides; approvals travel only through a browser where you are already signed in.

Where it stops

Tool payloads are in the MCP reference, and the model they describe is the zone map.