Skip to main content
Glama

fleet-of-one-mcp-server

Proof-of-production tools for AI coding agents — the core Fleet of One 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

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

Related MCP server: sabba

Use it with Claude Code

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

{
  "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.

MIT.

Available Tools

2 tools
check_reproCheck reproduction (bug-first)A

Bug-first discipline: before fixing a bug, confirm you actually reproduced it. Runs a command you expect to FAIL and returns PASS only if it genuinely fails (non-zero exit) — i.e., the bug is reproduced. If the command passes, you haven't reproduced the bug yet and shouldn't start 'fixing' it.

Inputs: repro_command (required), cwd, timeout_seconds. Returns: reasons, verdict, evidence, exit_code, +2 more

verify_doneVerify "done"A

Prove a task is actually complete before trusting an agent's "done" claim. Runs the given test command and, if the directory is a git repo, diffs the actual changes. Returns PASS only if the tests pass (exit 0) and — when expect_changed is provided — every claimed path actually changed. This is the gate between "agent says done" and "I believe it."

Inputs: test_command (required), cwd, claim, expect_changed, +1 more. Returns: reasons, verdict, evidence, timed_out, +4 more

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    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.

    Related MCP Connectors

    Related MCP Servers