The MCP bridge

The approved stories and acceptance criteria live in the repo at .linebreak/spec/. The bridge is how that folder becomes the working instruction your coding agent is holding while it writes, in Claude Code, Cursor, Codex, or anything else that speaks MCP.

Git is the transport. The bridge reads .linebreak/spec/ from the working tree. No network calls, no backend, no LineBreak account: a developer who was merely handed a clone gets all of it.

Install

pip install linebreak-gate

linebreak-gate mcp install --editor claude-code   # writes .mcp.json in the repo
linebreak-gate mcp install --editor cursor        # writes .cursor/mcp.json
linebreak-gate mcp install --editor codex         # appends to ~/.codex/config.toml
linebreak-gate mcp install                        # prints the generic stdio config

An existing config is merged or printed, never silently overwritten. Repo configs carry no absolute paths, so every clone and teammate gets a working setup.

One-time enable: editors do not auto-start MCP servers a repo brings with it; that’s their prompt-injection guard, and it’s the right call. On first open, approve or enable the linebreak server when prompted (Cursor: Settings → MCP → enable; Claude Code: approve the project server prompt).

The six tools

Tool	What it returns
`list_stories`	Every approved story: id, title, epic, local status, criteria count.
`get_story`	One story in full: every acceptance criterion with its id, statement, and check (type, payload, and `when: release` for criteria only the release gate evaluates) (`build` \| `tests` \| `command` \| `manual`). The payload that matters: the approved criteria as context before the agent writes a line.
`next_story`	The next approved story not yet done, per local story state.
`set_story_status`	Record progress: `doing` \| `review` \| `done`. Local story state only: the bridge’s single write.
`check_story`	Run that story’s criteria against the working tree with the same engine CI runs: pass \| fail \| needs-signoff per criterion, so the agent verifies its work before pushing instead of discovering it at the merge.
`spec_status`	Is there an approved bundle, its version and approver, and whether the approval signature is present and valid, verified entirely offline.

What the agent cannot do

It cannot change the approved standard. No tool can write, edit, or invalidate an approved criterion. Criteria change only by editing the draft and re-approving (with a human on the record), and the gate verifies the result at merge.

Honest states

No .linebreak/spec/ in the repo: every tool says “no approved spec found in this repository” and exits cleanly. A fact, not an error.
Unsigned bundle: everything works; spec_status reports unsigned rather than implying assurance that does not exist.
Signature present, no verification key configured: reported as signed-unverified; the hash comparison still detects tampering.
Bundle edited after approval: spec_status reports invalid loudly, and reads carry a warning. The MCP tools are not blocked (blocking at merge is the gate’s job), but tampered criteria are never presented as approved.

No MCP? The CLI says the same things

linebreak-gate spec list          # every approved story + criteria
linebreak-gate spec next          # the next approved story not yet done
linebreak-gate spec show S3       # one story: criteria, statements, check types
linebreak-gate spec check S3      # run that story's checks (0 pass / 1 fail / 2 tool error)