Skip to main content
Glama
README.md
# fleet-of-one-mcp-server

Proof-of-production tools for AI coding agents — the core [Fleet of One](https://fleetofone.dev) discipline as callable MCP tools. Make **"done" earn itself.**

Two tools, one job: stop trusting an agent's word for it.

| Tool | What it does |
|---|---|
| `verify_done` | Runs your test command and, in a git repo, diffs the actual changes. Returns **PASS** only if tests pass (exit 0) and every claimed change is really there. The gate between "agent says done" and "I believe it." |
| `check_repro` | Bug-first discipline: runs a command you expect to **fail** and confirms it actually fails, so you've reproduced the bug before you start fixing it. |

It only ever runs the command **you** pass, in the directory **you** specify. No network, no file changes of its own. Local stdio server.

## Install

```bash
npm install
npm run build
npm test        # end-to-end smoke test against the built server
```

## Use it with Claude Code

Add to your MCP config (e.g. `.mcp.json` in your project, or the global config):

```json
{
  "mcpServers": {
    "fleet-of-one": {
      "command": "node",
      "args": ["/absolute/path/to/fleet-of-one-mcp-server/dist/index.js"]
    }
  }
}
```

Then an agent can call `verify_done` before claiming a task is complete:

```
verify_done(test_command="npm test", expect_changed=["src/auth.ts"], claim="wired up login")
→ PASS / FAIL with the test exit code, the real git changes, and the evidence tail.
```

## The free skills this is built from

`proof-of-production-lite`, `bug-first-tdd`, and `agent-lane-operations-lite` — the free MIT starter repo: <https://github.com/Johnny-Martinez/fleet-of-one-free>

The full operating system (95-page playbook, 27 skills, 13 tool dossiers) is [Fleet of One](https://fleetofone.dev/?utm_source=github&utm_medium=referral&utm_campaign=fo-organic-launch&utm_content=freerepo-readme-cta).

MIT.

TDQS

A4.4/5.0

Scored across 2 tools

Disambiguation5/5

verify_done and check_repro serve entirely distinct purposes: one validates success (tests pass and changes made), while the other validates expected failure (reproduction of a bug). No overlap or confusion between them.

Naming Consistency5/5

Both tool names follow the same verb_noun pattern with lowercase and underscores: verify_done and check_repro. The naming is consistent and predictable.

Tool Count3/5

At 2 tools, the set is on the borderline of feeling thin, but it is acceptable for its narrow verification-focused domain. The tools cover the two primary verification gates without being excessive.

Completeness4/5

The two tools cover the core verification lifecycle: confirming task completion and confirming bug reproduction. Minor gaps exist, such as verifying partial changes or checking for regressions, but these are workable for the stated purpose.

Maintenance

ActivityStale
ResponsivenessNo issues