fleet-of-one-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| verify_doneA | 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." |
| check_reproA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
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.
Both tool names follow the same verb_noun pattern with lowercase and underscores: verify_done and check_repro. The naming is consistent and predictable.
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.
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.