---
title: "An MCP server that asks the gate, never opens it"
description: "Zone map, intake, scoping, status, file history and related tasks, from your session. Transitions are the gate's call; no tool approves access."
url: https://commitcycle.com/mcp/
language: en
---

# File and scope work without leaving the session

> Zone map, intake, scoping, status, file history and related tasks, from your session. Transitions are the gate's call; no tool approves access.

MCP Server Shipped

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. No tool here approves an access request, and none opens a zone by itself: `cc_start` asks, and only the gate opens one. A transition is a question put to the gate, never a power the tool holds.

**Claude:** Add the board’s connector URL and Claude files and scopes the task from the chat — nothing to install. It cannot approve access: the gate and the zone’s owner decide.

**Cursor:** The same connector in Cursor: start the task, read why a file last changed, hand the work in. With the connector alone, nothing on the machine blocks a write.

## 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](https://commitcycle.com/claude-code/) wires it up for you.

## The seven tools

| Tool           | What it does                                                                                                                      |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| `cc_zones`     | The zone map as the board holds it — paths, risk, owners                                                                          |
| `cc_intake`    | One line into Triage. It does not start anything                                                                                  |
| `cc_interview` | Draft the four fields, reconciled against the real zone map                                                                       |
| `cc_scope`     | Save those four answers onto the task                                                                                             |
| `cc_status`    | A single task, or everything in flight. Read-only                                                                                 |
| `cc_why`       | Which tasks changed a file or folder, newest first, with the goal each was opened for. Read-only                                  |
| `cc_search`    | Up to five tasks related to a request or to files — by meaning where the board has it on, by shared files and by words. Read-only |

`cc_search` joined both servers on the trunk on 2026-10-13. The release that npm and the plugin install, 0.1.25 (2026-10-12), predates it and serves the first six.

## 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. For zones that are not high-risk, that means `cc_start` can open them with no person involved; a high-risk zone still waits for its owner. [The reference](https://commitcycle.com/docs/reference/mcp/) 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 come from a person in the console — or from `cycle approve`, the weaker door, recorded as such, which a paired machine can use only on a one-member board.

## Where it stops

- **It never decides what the hook decides.** Enforcement is local and offline; this server is not in that path and an outage cannot open a zone.
- **It holds no second copy of the gate's rules.** The day it starts judging whether a spec is complete, it can disagree with the gate — and a tool that disagrees with the gate is worse than no tool.
- **It reads the board, not your disk.** For what is open on this machine right now, `cycle status` is the honest answer; the grant is local and this server deliberately cannot see it.

Tool payloads are in [the MCP reference](https://commitcycle.com/docs/reference/mcp/), and the model they describe is [the zone map](https://commitcycle.com/zones/).

## Questions this page answers

### Can the MCP server start work or grant access?

Grant access, never — an approval arriving through a tool the agent calls is authenticated by a token the agent holds, so the board could not tell your yes from the agent's own. Start work, only by asking: the connector's cc\_start requests the transition and the gate decides it, by the same rules whichever client asks.