Integrates with Hermes as an MCP host, where the server's loop is driven by Hermes' internal loop mechanism calling tools each turn.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@super-loop-mcp Use super loop on this. Mine my sessions for a better loop, then keep improving it until I stop you."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A referee for self-improving AI agent loops. Sling mines your past agent sessions for the workflows that actually worked, tries to improve them, and refuses to call anything "better" or "done" without measured proof — and it never stops until you stop it.
local-first · zero dependencies · Node ≥18 · MCP over stdio
When you put an AI agent on a repetitive improvement task — "make this prompt/workflow better, and keep going" — three things tend to go wrong:
it says "done" when it isn't,
it skips steps it was told to follow,
it stops early because it "thought hard" and felt finished.
Sling is the supervisor that doesn't allow that. It sits between you and the AI and acts like a strict lab referee:
It holds the improvement procedure (a "loop") and hands the agent one step at a time — the next step only unlocks once the current one has left real evidence on disk.
It keeps a sealed scorecard. The agent can't grade its own work; Sling measures the result itself and re-checks it from the sealed record before accepting any "this is better."
It never declares victory. The run keeps going until you say stop — and it says so, plainly, the whole time:
WARNING: You are the stop condition. This loop does not stop until you stop it.
Everything runs on your machine. Nothing is uploaded.
Mines your history — reads back through your past agent sessions to surface the loops/workflows that genuinely worked (the Strip Miner).
Improves a loop — takes a loop and tries to make it better, generation after generation (Loop-de-loop).
Only promotes real wins — a change is "promoted" only if it is measurably better on a frozen test and re-verified from sealed bytes; otherwise it is blocked.
Keeps your authorship — your loops never leave your machine, and it never overwrites your canonical loop without you.
Related MCP server: Cortex MCP
cd super-loop-mcp
npm test # full node:test suite (199 checks) — no install, zero deps
npm run demo # spawns the real server and drives a whole campaign over stdio (38/38 checks)
npm run verify # prove the bundled loop hashes against the mandated contractThen point your MCP host (e.g. Claude Code) at it:
{
"mcpServers": {
"super-loop": {
"command": "node",
"args": ["/path/to/super-loop-mcp/src/server.mjs"],
"env": { "SUPER_LOOP_HOST": "claude" }
}
}
}Set SUPER_LOOP_HOST in the server env so the run hands the agent a host-correct setup checklist at start. The value is any host id or alias from the host registry — e.g. "claude", "codex", "zcode", "cursor", "opencode". Ready-made config snippets per host live in examples/mcp/. State lives under SUPER_LOOP_HOME (default <package>/.super-loop). Nothing leaves your machine.
In your MCP host, tell the agent:
"Use super loop on this. Mine my sessions for a better loop, then keep improving it until I stop you."
initialize_loop_run returns a hostSetup block — a numbered, host-correct checklist the agent runs to put itself into continuous mode and start the phase gate:
Claude Code → run /goal with an operator-stop objective (progress-driven: the next turn starts automatically when the previous finishes; docs). /loop is for interval polling or self-paced wake-ups, not a convergence campaign.
Codex → create a /goal and keep it active across turns.
Other hosts → see the host compatibility matrix for the per-host driver, or use the super-loop-run CLI fallback.
The run then streams the loop one phase at a time, measures every result itself, and never marks itself done — EXEC_DISABLED, saturation, and no-improvement advisories are checkpoints, not stops. You are the only stop condition.
Infinite or bounded — your call. By default a run is infinite: it never self-stops; campaignContinues stays true until you stop it. Give it a limit at init (config.maxCycles, e.g. 5) and it flips to bounded mode — when it reaches the limit (or the no-improvement/exhaustion advisory), it returns campaignContinues: false + boundedComplete: true and tells the agent it may stop the /loop and report the final state, instead of spinning forever. Either way nothing auto-promotes, any pending dashboard reviews still wait for you, and the run resumes by runId if you raise the limit. The limit is tool-enforced and set once at init — the model can't talk its way to "done."
If your first message already says the goal and "just go," the agent can skip the ask-once questions and start with surfaced default assumptions (mine → improve, whole history, best-first).
For a campaign that drives itself until you drop a stop-file — no host turns:
SUPER_LOOP_ALLOW_EXEC=1 super-loop-run \
--config examples/campaign.json \
--stop-file ./STOPThis launches real frontier workers itself (opt-in via SUPER_LOOP_ALLOW_EXEC=1), serves the click-and-done dashboard at http://127.0.0.1:8787, and stops only when you create ./STOP (or Ctrl-C). Copy examples/campaign.json (or the improve-only examples/campaign-improve-only.json) and edit task, routes, the benchmark, and the improve target's baselineContent. The autonomous CLI runs the supervisor (mine → improve → re-mine) — it does not resume a reactive MCP run mid-phase.
Super Loop is MCP-first (the portable layer), with the continuous driver chosen per host from the host registry, and the super-loop-run CLI as the universal fallback. The driver families collapse ~every agent into a few mechanisms, so you don't ship a bespoke string per host:
Host | Driver family | Tier | Continuous driver | Verified |
Claude Code |
| 1 |
| ✅ |
Codex |
| 1 |
| ✅ |
ZCode |
| 1 |
| ⚠︎ |
OpenCode |
| 1 |
| ⚠︎ |
Cursor |
| 2 | none — continuation rules snippet | ⚠︎ |
Kilo Code |
| 2 | none — rules snippet (CLI fork = tier 1 with a goal plugin) | ⚠︎ |
OpenClaw |
| 2 | config ( | ⚠︎ |
Hermes |
| 3 | its own loop — call tools each turn | ⚠︎ |
Factory Droid |
| 2 | Super Loop runs inside a Mission worker | ⚠︎ |
MiniMax Mini-Agent |
| 3 | its own loop, or the CLI fallback | ⚠︎ |
anything else |
| 3 |
| — |
Three tiers:
Native goal (Claude/Codex/ZCode, OpenCode+plugin) — engage /goal with an operator-stop objective.
MCP + continuation contract (Cursor, Kilo IDE, OpenClaw, Hermes) — no reliable continuous slash command, so ship the continuation rules snippet: continue on every tool result, checkpoint != stop, cold-start fresh.
CLI owns the loop (super-loop-run) — for any headless/host-less run; same referee, no host babysitting.
⚠︎ verified:false entries are modeled from the design and link their docs in the registry — confirm the exact command in your build before relying on it. host_capability_preflight returns the resolved host profile (tier, driverFamily, setupHint) and, when the host is unknown, the full matrix.
Everything below is the engineering detail behind the one-minute summary.
Drop a 300+ line loop into a model's context and it may ingest the whole thing, skip the structure, and treat an unverified argument as a test. Sling fixes that with hard mechanics:
Ask-once — starts with a brief explanation plus a few short questions once:
the goal;
the path — improve a loop you already run, discover/find a loop (optionally scouting a public loop library), or mine your whole history (deep);
the loop or domain to start from;
corpus scope — your whole session history or a set number of loops, and best-first vs in-order (asked with an up-front warning that a run can take hours, days, or weeks depending on how deep it mines);
what "better" means (this becomes the frozen benchmark);
any task-specific limit;
and a final deeper-explanation offer, honored in the same response.
It never asks you to choose the model, promotion mode, or benchmark policy — the supervisor decides those from the task — and afterward it does not ask again or mark the campaign complete by itself. A fresh run also carries a cold-start notice: don't resume a prior campaign or assume a path from memory — infer only from this message and the answers (pass a runId to resume on purpose).
Phase-gated streaming — holds the loop inside the MCP and hands you the next section only after the current one has recorded evidence. No 1k-line dump.
Benchmark-first — the baseline is hash-locked and the scorecard is frozen before any challenger. Model self-reported metrics never count.
Frontier hypothesis engine — full tests need 3–5 hypotheses on frontier routes (haiku/mini/nano/lite/prior-gen rejected); one no-improvement run is never "perfect".
Promotion gate — promotion requires a tool-measured, deep-reverified result that moves the quality/cost frontier past threshold. Otherwise: BLOCKED.
Two surfaces share one engine: the reactive MCP (a host calls its tools — the in-conversation hook) and the autonomous driver (super-loop-run CLI / run_campaign tool) that drives the whole campaign itself and only stops on the operator stop-file. The whole point: a model cannot promote, upgrade, or call a loop "perfect" from reasoning alone — every decision is hooked through a tool that demands tool-measured artifacts on disk, and the operator is the only stop condition.
Built fresh, zero dependencies, runs on plain Node ≥18. The full private 345-line Strip Miner and the full private 75-line Loop-de-loop (Loop 2) live inside the supervisor, byte-identical to source and hash-locked, streamed one section at a time.
id | file | lines | sha256 | trigger |
|
| 345 |
|
|
|
| 75 |
|
|
These are the local big sources — the operator's full private cross-agent Strip Miner (with the old pause/complete language patched into checkpoint/continue semantics), not the short public miner. The server refuses to start, and the test suite fails, if either file's hash or line count drifts — so the short public miner can never be silently substituted.
Users add their own loops through a tool, not by hand-editing source:
loop_register { id:"my-loop", title:"My Loop", content:"<full loop text>" } → hash-locked, sectionized, persisted locally
loop_library → lists mandated (hash-locked) + your custom loops
loop_start { loop:"my-loop" } → streams it phase-gated, exactly like the mandated loopsCustom loops are sha256 hash-locked (write-once per version; overwrite:true makes a new version), get a safe id (no path traversal), persist under SUPER_LOOP_HOME/custom-loops/, and cannot collide with or overwrite the mandated Strip Miner / Loop-de-loop. They stream through the same phase gate. Nothing leaves your machine.
tool | what it enforces |
| autonomous supervisor (opt-in |
| ask-once (brief + a few short Qs: goal, path picker (improve / discover / mine + library scout), the loop/domain, corpus scope + order, what "better" means, a hard limit, deeper-explanation; no model/promotion/policy questions — the supervisor decides those); stores every user message with a sha256 hash; picks a frontier model; surfaces the stop-condition notice, the cold-start notice (fresh run), and the native-continuation notice (Claude/Codex |
| add your own loop to the local MCP: hash-lock, safe id, sectionize, persist locally; never overwrites a mandated loop |
| list mandated (hash-locked) + custom local loops |
| begin phase-gated streaming of any loop (mandated or custom); returns section 0 only |
| next section iff the current one has evidence, else |
| lightweight phase evidence |
| persist a raw artifact + sha256; |
| propose scorecards (≥1 value dim, ≥1 cost dim, ≥1 case, optional deterministic |
| set the tool-computed baseline bar; a caller-reported measurement is rejected |
| 3–5 frontier hypotheses; benchmark-first; rejects banned routes |
| one full test = 3–5 frontier agents, each tool-computed; aggregates vs the bar; reports quality authority |
| opt-in ( |
| re-derive metrics from the sealed raw bytes and confirm they reproduce (a tampered number cannot survive) |
| promote only on measured + reverified frontier movement; a quality win the MCP can't tool-verify routes to the dashboard ( |
| the supervisor hook — a worker proposes a transition packet (promote/advance_phase/change_baseline/change_benchmark/saturate); only a supervisor-accepted transition is progress; completion/stop intents refused |
| mark a lane saturated → supervisor auto-transitions to the next lane (Strip Miner → Loop-de-loop); never pauses/stops |
| read-only lane/target queue, auto-transitions, 30-batch retirement + 10–15 advisory accounting, pending dashboard review (never blocks) |
| records the next lane + first concrete action; it does not clear the obligation until a real progress tool runs |
| queue/list Approve/Sludge items only; model-callable resolve is blocked |
| render the polished always-on local dashboard with the stop-condition notice |
| reproducible markdown campaign report |
| local report of which frontier-agent CLIs are installed on PATH (filesystem stat only, never executes, not SOTA/web research) plus the resolved host profile — |
NOT_INITIALIZED · PHASE_SKIP · BASELINE_FIRST · BASELINE_LOCKED · BENCHMARK_FIRST · BENCHMARK_FROZEN · WEAK_BENCHMARK · BASELINE_BAR_FIRST · HYPOTHESIS_COUNT · BANNED_ROUTE · BUILDER_ROUTE · FULLTEST_AGENTS · MODEL_REPORTED · MEASUREMENT_AUTHORITY · QUALITY_UNVERIFIED · NO_SCORE_MATRIX · NOT_REVERIFIED · BELOW_THRESHOLD · BELOW_FLOOR · STAGED_TRADEOFF · OPERATOR_IS_STOP · DASHBOARD_ONLY · NO_ACTIVE_LANE · EXEC_DISABLED · EXEC_FAILED · LOOP_EXISTS · LOOP_SOURCE
By default the server never executes commands (audited posture). Set SUPER_LOOP_ALLOW_EXEC=1 to let Sling own benchmark execution end-to-end: execute_full_test launches the frontier workers itself (allowlisted claude/codex/glm/gemini only, via execFile with no shell, prompt passed on stdin so untrusted text never reaches argv), captures each output, parses real token usage when the CLI reports it, enforces a hard timeout, and feeds the tool-captured bytes through the same gate. This closes the last self-report hole — when the supervisor launches the worker, there is no model-supplied run-log to fabricate. A failed/timed-out/non-allowlisted launch is an invalid batch and does not count toward retirement.
The autonomous driver sits on top of that — the difference between "a supervisor you call" and "a harness that drives itself":
SUPER_LOOP_ALLOW_EXEC=1 node scripts/run-campaign.mjs --config campaign.json --stop-file ./STOPIt runs the whole loop unattended (intake → mine → improve targets → validate every worker → bank Stones → advance/retire → re-mine) and only stops when you create the stop-file. The same logic is the run_campaign MCP tool, bounded by maxBatches for the in-call version. An MCP alone is reactive (a host calls it); the supervisor is what makes Sling self-driving.
Workers run on the real CLIs via stdin (claude -p --output-format json, codex exec --json) — the prompt never touches argv (no injection), and the real answer text + token usage are extracted for benchmarking. Benchmark modes: oracle (deterministic → auto-promote on a measured win) and judge (an independent Opus/GLM judge scores baseline-vs-challenger real outputs under a rubric → subjective → queues to the dashboard, never auto-promotes; the challenger never scores itself).
initialize_loop_run → brief + ask-once (a few Qs) → answer → INITIALIZED
loop_start strip-miner → section 0
observation_record (phase 0) → request_next_phase → section 1 → … (gated)
artifact_record role=baseline → hash-locked
benchmark_propose → benchmark_select → scorecard frozen
artifact_record measurement → benchmark_run arm=baseline → bar set (tool-measured)
register_hypotheses (3–5 frontier)
test_hypothesis (3–5 agents, tool-measured) → MOVED_FRONTIER | NO_IMPROVEMENT
reverify_run → promotion_request → PROMOTE | BLOCKED
update_dashboard / report_export → checkpoint; lanes keep runningTwo distinct thresholds, neither of which stops the campaign:
Risk advisory (10–15, configurable): after ~12 consecutive valid no-improvement full tests the supervisor raises an economic-exhaustion risk advisory and opens dashboard review — it only reports risk, it does not stop.
Branch retirement (30 valid batches): a branch retires only after 30 valid full real test batches (3–5 frontier workers each) with no qualifying improvement, then the supervisor auto-pivots to the next lane. Invalid / fake-metric / early-stopped / summary-only batches are blocked upstream and never count.
If the Strip Miner saturates, the supervisor auto-transitions (Strip Miner → Loop-de-loop, or the next improvement lane) via report_saturation — never a pause/await/stop. Checkpoint/report/dashboard/refused-terminal/saturation/retirement events persist a machine-readable continuation obligation until a real progress tool runs. continue_run records the model's next-lane commitment but deliberately cannot clear the obligation by itself. Only the operator stops the campaign.
Zero dependencies on purpose. No SDK, nothing to npm install that can fail or time out, nothing phoning home. The MCP transport is ~90 lines of newline-delimited JSON-RPC in src/server.mjs. There is nothing to install.
Tool-computed measurement authority. The MCP derives every metric from the recorded raw bytes — tokenCost always (a deterministic token estimate), quality via the frozen benchmark's deterministic oracle when one exists. A number the model types is caller-reported and is refused by the benchmark/test gates (MEASUREMENT_AUTHORITY). reverify_run re-derives from the sealed bytes, so a tampered number cannot survive. The honest boundary, stated plainly: the MCP cannot prove the recorded bytes came from a real frontier-agent run unless it launched the worker (the opt-in live executor), and it cannot judge subjective quality without an oracle. Subjective quality routes to the dashboard for a human and never auto-promotes (QUALITY_UNVERIFIED); deterministic, oracle-scored quality promotes autonomously. In short: deterministic → tool-measured, subjective → dashboard.
Host capability preflight, no execution. host_capability_preflight resolves known frontier-agent CLI names against PATH with a filesystem stat — it never spawns a command, never probes a model-supplied binary, and is not SOTA/web research. Presence on PATH ≠ working auth, and it says so.
Anti-tampering. Baseline and benchmark are write-once within a cycle; changing either needs an explicit new epoch + rationale.
Path hardening. runId and artifact ids are validated before touching disk, and sourcePath reads are refused so a model cannot turn the MCP into a local-file reader. Submit artifact bytes through content.
Dashboard-only human review, with a real apply path. The model can queue/list Approve/Sludge items (and may propose a loop adoption by queuing a review that carries the improved loop text), but human_review_request { action:"resolve" } returns DASHBOARD_ONLY — the model can never approve its own work. Click-and-done: the autonomous campaign serves the dashboard (or run node scripts/dashboard-server.mjs); open it and just click Approve/Sludge. The click POSTs to the local server (127.0.0.1 only, cross-origin refused), which queues it to the run inbox, and the running campaign adopts it on its next tick — no file, no command, model-independent, non-blocking. (Headless fallbacks: save the dashboard's Export to runs/<runId>/inbox-decisions.json for the supervisor to auto-apply, or node scripts/apply-decisions.mjs --file <export>.) Approving a loop-adoption review installs the improved loop as a new versioned custom loop (the prior version is archived for rollback via operator.rollbackLoop), which loop_start then streams next cycle. The mandated canonical loops are immutable and never touched. Applying is non-blocking — the campaign never pauses for it, and adoption is never a model-callable tool (it lives under api.operator, off the tools/call surface). This is how a proven improvement actually becomes the loop Sling runs.
Continuation is a host obligation, stated honestly. An MCP cannot force the host agent loop to keep running — only the host can (which is why the agent is told its native continuous command — Claude Code / Codex /goal, with /loop as Claude's polling alternate, or the per-host driver from the registry — on start). What the MCP can do, and does: every report / dashboard / saturation / no-improvement / refused-terminal event persists a machine-readable continuation obligation with a concrete next tool+lane, and continue_run records intent without clearing it (only a real progress tool clears it). The MCP makes stopping early visibly incomplete; it does not pretend to be the host scheduler. The operator is the only stop condition.
Never overwrites your canonical loop. Promotion records an internal champion; changing the canonical loop file is HUMAN-GATED and left to you.
Standalone by design.
loops/ bundled hash-locked loop sources (+ MANIFEST in constants)
src/
server.mjs MCP stdio JSON-RPC transport + tool schemas
engine.mjs Sling core — every tool handler + gate
loops.mjs registry, hash-lock, sectionizer (mandated + custom loaders)
measure.mjs tool-computed measurement (derive cost/quality from bytes) + honest boundary
executor.mjs opt-in live worker execution (allowlist, execFile, stdin) — off by default
supervisor.mjs autonomous campaign driver (validate → accept/re-enter boundary)
host.mjs host capability preflight (PATH presence only, no execution)
models.mjs frontier-route policy (banlist/allowlist)
scorecard.mjs promotion frontier rule + score matrix
store.mjs local atomic JSON persistence (runs + custom-loops)
dashboard.mjs polished dashboard.html + markdown report
constants/util shared facts + helpers
scripts/ demo.mjs (live proof), run-campaign.mjs (autonomous CLI, serves the dashboard),
dashboard-server.mjs (zero-dep served dashboard: click Approve/Sludge → adopt),
apply-decisions.mjs (operator-only headless fallback), verify-sources.mjs
test/ node:test suites (sources, ask-once, phase gate, benchmark,
hypotheses, promotion, hook, dashboard, transport, security,
loop library, measurement authority, host preflight, executor,
supervisor, adoption, dashboard-server)Persist a raw artifact (run log, baseline copy) with a sha256 hash. role:"baseline" hash-locks the baseline (write-once; tampering refused). Pass measurement:{tokenCost,quality} so the artifact can serve as a tool-measured, reverifiable measurementRef. sourcePath reads are disabled; pass explicit content.
| Name | Required | Description | Default |
|---|---|---|---|
| loop | No | ||
| name | No | ||
| role | No | baseline | evidence | runlog | |
| phase | No | ||
| runId | Yes | ||
| content | No | ||
| newEpoch | No | ||
| rationale | No | ||
| sourcePath | No | disabled; pass content instead | |
| measurement | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: hash-locking for role='baseline' (write-once, tamper-proof), disabling sourcePath, and using measurement for tool-measured artifacts. However, it does not cover idempotency, error handling, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the core action. Each sentence provides essential information without redundancy: first states the primary function, then adds critical constraints on role and measurement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description covers the main purpose and key constraints but lacks details on return values, error cases, and usage of other parameters like loop, phase, and rationale.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%), but the description adds meaning to parameters like role (hash-lock behavior), measurement (tool-measured), and sourcePath (disabled). It does not address other parameters (loop, name, phase, content, etc.), leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Persist a raw artifact (run log, baseline copy) with a sha256 hash.' It specifies the resource (artifact) and action (persist), and distinguishes from siblings by mentioning hash-locking for baselines and measurement capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (e.g., for persisting artifacts with integrity, especially baselines) but does not explicitly state when not to use it or compare with alternatives. Sibling tools like observation_record or run_campaign are not mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose one or more benchmark scorecards built from real prior uses/failures. Each needs ≥1 task-value dimension, ≥1 resource/cost dimension, and ≥1 concrete case, or it is rejected as a hand-waved benchmark.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | ||
| benchmarks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions the core action and rejection condition, but lacks details on side effects, error handling, permissions, or state changes. For a creation tool, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, and a second sentence adding essential constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested object with 7 subfields) and no output schema, the description only covers the high-level requirement. It omits explanations of subfields (oracle, qualityScale, comparisonRule) and what constitutes a 'concrete case', making it incomplete for an agent to correctly formulate inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds some meaning by implying the 'benchmarks' array must contain subfields (task-value dimensions, resource dimensions, cases), but it does not explain individual properties like 'name', 'oracle', 'qualityScale', etc. Many parameters remain unclear to an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Propose') and the resource ('benchmark scorecards built from real prior uses/failures'). It includes specific constraints (≥1 task-value dimension, ≥1 resource/cost dimension, ≥1 concrete case) that help differentiate it from sibling tools like benchmark_select or benchmark_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong context for when to use (proposing benchmarks with real prior uses/failures) and includes rejection criteria (hand-waved benchmarks). However, it does not explicitly state when not to use it or mention alternatives like benchmark_select.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a tool-measured run of an arm through the frozen benchmark. arm:"baseline" sets the bar challengers must beat. Requires a measurementRef → a recorded raw artifact; model self-report never sets the bar.
| Name | Required | Description | Default |
|---|---|---|---|
| arm | Yes | "baseline" or a hypothesis id | |
| runId | Yes | ||
| measurementRef | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that measurementRef must be from a raw artifact and that model self-report never sets the bar, but does not describe other behavioral traits like whether it is destructive, permissions needed, or what the outcome of recording a run entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no wasted words. The first sentence states the purpose, the second adds a critical constraint. Front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is adequate for the basic purpose and a key constraint, but lacks details on return values, side effects, or integration with sibling tools. It is minimally complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has low coverage (33%), but the description adds meaning for 'measurementRef' (recorded raw artifact) and 'arm' (baseline sets bar). This compensates for the missing schema descriptions, though 'runId' remains unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action 'Record a tool-measured run of an arm through the frozen benchmark' and distinguishes the arm 'baseline' as a special case that sets the bar. This is a specific verb+resource and differentiates from siblings like 'reverify_run' or 'initialize_loop_run'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: requires a measurementRef from a recorded raw artifact, not model self-report. While it doesn't explicitly exclude alternatives, it gives enough guidance on prerequisites and the special role of 'baseline'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Freeze ONE proposed benchmark as the immutable scorecard for this cycle. Requires the baseline to be hash-locked first. Changing a frozen benchmark needs a new epoch + rationale.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | ||
| newEpoch | No | ||
| rationale | No | ||
| benchmarkId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation freezes the benchmark immutably and requires a precondition, but does not detail side effects, permissions, error conditions, or return values. The description adds value but lacks comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two sentences that efficiently convey purpose, precondition, and change guidance. No unnecessary words; information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no output schema, and no annotations, the description lacks completeness. It does not explain how to use the parameters (especially newEpoch and rationale beyond the change scenario), nor does it describe the return value or error conditions. More detail is needed for full self-containment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It hints at the roles of 'newEpoch' and 'rationale' (for changing a frozen benchmark), but does not explain the other parameters (runId, benchmarkId) or provide explicit mapping. This is insufficient for four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'freeze' and the resource 'proposed benchmark as the immutable scorecard for this cycle,' which distinguishes it from sibling tools like benchmark_propose and benchmark_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies a precondition: 'Requires the baseline to be hash-locked first.' It also notes that changing a frozen benchmark requires a new epoch and rationale, providing clear usage context. However, it does not explicitly mention alternative tools or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only supervisor status: the lane/target queue, auto-transitions, branch-retirement accounting (30 valid no-improvement batches), the 10-15 risk advisory band, and how many dashboard review items are pending. Pending review never blocks the campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares 'Read-only' (non-destructive) and notes that pending review does not block the campaign, adding useful behavioral context. However, with no annotations, it lacks details on authentication, error handling, or side effects like rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence packed with specifics, front-loaded with 'Read-only supervisor status'. Efficient but slightly dense; could be broken into bullets or shorter clauses for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple read-only tool with one parameter: enumerates key data points. However, lacks explanation of output format or how the status items relate, and does not reference capabilities like pagination or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `runId` has 0% schema description coverage and the tool description does not mention it at all. The agent receives no guidance on its format, purpose, or how to obtain it, leaving the parameter semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'Read-only supervisor status' and lists specific resources (lane/target queue, auto-transitions, branch-retirement accounting, risk advisory band, pending review items). It distinguishes from sibling tools like loop_next or reverify_run which are action-oriented, but does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. any of the 23 siblings. It does not specify prerequisites (e.g., runId must be valid) or contexts where this status check is appropriate before actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the next runnable improvement lane and first concrete action after reports, dashboards, saturation findings, no-improvement advisories, or refused terminal/checkpoint intents. This never asks the user and never marks the campaign complete. It does not clear the continuation obligation by itself; a real progress tool must run next.
| Name | Required | Description | Default |
|---|---|---|---|
| lane | Yes | the next runnable lane/bottleneck being pursued now | |
| runId | Yes | ||
| rationale | No | ||
| firstAction | Yes | the concrete next tool/action the model is about to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool never asks the user, never marks the campaign complete, and does not clear the continuation obligation by itself. This provides key behavioral traits for safe invocation. It does not mention any destructive actions, which is appropriate given it is a recording tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, efficiently conveying purpose and key behavioral constraints without extraneous words. The first sentence front-loads the primary action, and the second sentence clarifies limitations. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 50% schema coverage, no output schema, and no annotations, the description adequately covers usage context and behavioral traits. It explains when to use and what the tool does not do, which is sufficient for a recording tool. It could optionally mention the return value, but that is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with 'lane' and 'firstAction' having descriptions. The description adds context by explaining 'next runnable improvement lane' and 'first concrete action,' aligning with parameter meaning. However, 'runId' (required) and 'rationale' (optional) are not elaborated in the description, leaving a gap for those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records the next runnable improvement lane and first concrete action after specific events. It uses a specific verb ('record') and resource ('run', 'lane', 'action'), and distinguishes from sibling tools by noting it never asks the user or marks the campaign complete, which is unique among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool (after reports, dashboards, saturation findings, etc.) and states it does not mark the campaign complete nor clear the continuation obligation, implying it is an intermediate step. It advises that a 'real progress tool must run next,' providing clear guidance on context, though it does not explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The supervisor decision hook. A worker proposes a transition packet; only a supervisor-accepted transition counts as progress. Reasoning alone is never proof. Allowed transition intents: promote | advance_phase | change_baseline | change_benchmark | saturate. Completion/stop-style intents are refused (the operator is the only stop condition).
| Name | Required | Description | Default |
|---|---|---|---|
| loop | No | ||
| runId | Yes | ||
| intent | Yes | ||
| newEpoch | No | ||
| rationale | No | ||
| hypothesisId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool is a decision hook where only supervisor-accepted transitions count as progress, and that completion/stop intents are refused. While this gives some behavioral insight, it omits details on success/failure responses, side effects, or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that front-load the core purpose and constraints. However, it could be better structured by grouping related information (e.g., listing parameters with brief explanations).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations, and 0% schema coverage), the description is incomplete. It fails to explain crucial parameters like runId, rationale, or hypothesisId, and does not describe return values or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only adds meaning for the 'intent' parameter by listing allowed values. The other five parameters (runId, loop, newEpoch, rationale, hypothesisId) are left completely unexplained, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a supervisor decision hook for transition intents, listing allowed intents and explicitly stating what is refused. However, it does not directly differentiate from sibling tools like promotion_request or loop_next.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (worker proposing a transition requiring supervisor approval) and what intents are refused. However, it lacks explicit guidance on when not to use it or references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SUPERVISOR-EXECUTED full test (off by default; opt in with env SUPER_LOOP_ALLOW_EXEC=1). Sling itself LAUNCHES 3-5 allowlisted frontier workers (claude/codex/glm/gemini binaries on PATH) via execFile (never a shell), captures each output, and feeds the tool-captured bytes through the same gate as test_hypothesis — so there is no model-supplied run-log to fabricate. A failed/timed-out/non-allowlisted launch is an invalid batch and does not count toward retirement. Without the opt-in this returns BLOCKED (EXEC_DISABLED) and you record run-logs via artifact_record + test_hypothesis instead.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | ||
| prompt | Yes | the loop + task the launched worker should actually run | |
| routes | Yes | 3-5 frontier worker routes to launch (each must map to an allowlisted binary) | |
| timeoutMs | No | per-worker hard timeout (default 600000) | |
| hypothesisId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes exact execution behavior: launches 3-5 allowlisted workers via execFile, captures output, no model-supplied run-log. Also states what happens when opt-in is missing (returns BLOCKED). No annotations provided, so description fully covers behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single dense paragraph but front-loads key information and every sentence adds value. Could benefit from structure but remains clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides context on execution environment, opt-in, and alternatives, but lacks detail on return format and does not explain all parameters (runId, hypothesisId) thoroughly. Adequate given tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 60% with descriptions for prompt, routes, and timeoutMs. The description adds context for routes (3-5 frontier worker routes) but does not explain runId or hypothesisId beyond what's in the schema. Adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a supervisor-executed full test that launches frontier workers, distinguishing it from sibling tools like test_hypothesis which record run-logs without execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's off by default with opt-in (env variable), and specifies alternatives (artifact_record + test_hypothesis) when exec is disabled. Also clarifies that failed launches don't count toward retirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local capability report: which known frontier-agent CLIs (claude, codex, gemini, opencode, optional glm) are installed on PATH, PLUS the resolved host profile (driverFamily, tier, setupHint, and the host matrix when SUPER_LOOP_HOST is unknown). Filesystem stat only — NEVER executes a command, NEVER probes arbitrary binaries, and is NOT web/SOTA research. Presence on PATH is not proof of working auth.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | No | optional; only used to journal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: filesystem stat only, no command execution, no arbitrary binary probing, not web/SOTA research, and caveat about auth. This is comprehensive and honest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise, front-loaded sentences. First sentence states purpose, second sets boundaries, third provides important limitation. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity, no output schema, and full parameter coverage by schema, the description is complete. It covers purpose, constraints, and caveats, leaving no obvious gaps for an AI agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (runId) is fully described in the schema with 100% coverage; the description adds no further meaning. Baseline 3 is appropriate as the schema already documents it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a local capability report on installed frontier-agent CLIs and host profile, using specific verb 'report' and resource 'local capability'. It distinguishes itself from sibling tools like host_runtime_detect by focusing on CLI presence and host resolution without execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies safe usage ('NEVER executes a command') but lacks explicit when/when-not guidance or naming of alternatives. It does not contrast with sibling tools like host_runtime_detect or other inspection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advisory guess of which host runtime the agent is in, from which MCP config files exist on disk (per the host registry). READ-ONLY existence check — never reads file contents, never mutates config. SUPER_LOOP_HOST, if set, is authoritative. Returns a guess, the candidate hosts with evidence, and the CLI fallback; nothing is auto-applied.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | No | optional; only used to journal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states the tool is read-only, never reads file contents, never mutates config, and returns a guess with evidence without auto-applying anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences that front-load the purpose and efficiently cover all critical aspects without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is complete. It covers the purpose, behavior, output summary, and a key constraint (SUPER_LOOP_HOST). No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single optional parameter 'runId', with its description as 'optional; only used to journal'. The tool description does not add further semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: an advisory guess of the host runtime based on MCP config files. It uses specific verbs like 'detect' and 'guess', and distinguishes itself from siblings by emphasizing it does not read file contents or mutate config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that SUPER_LOOP_HOST is authoritative, providing some usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue a change for the operator’s Approve/Sludge dashboard or list pending items. This tool CANNOT resolve human review; approval/sludge is dashboard-only. Never blocks deterministic lanes — the loop keeps running.
| Name | Required | Description | Default |
|---|---|---|---|
| item | No | ||
| notes | No | ignored/refused; human decisions are dashboard-only | |
| runId | Yes | ||
| action | No | add | list (resolve is refused: dashboard-only) | |
| decision | No | ignored/refused; human decisions are dashboard-only | |
| reviewId | No | accepted only for rejected legacy resolve attempts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: queuing, listing, no resolution, and non-blocking nature. However, it lacks details on error handling or side effects like ignoring notes/decision fields (though schema covers some of these).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences front-loaded with core purpose, no wasted words, efficiently conveys key guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and key behavioral constraints. Lacks details on return values or what happens after queuing, but given no output schema and 6 parameters, the description is reasonably complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, so baseline is 3. The description does not elaborate on specific parameters beyond implying 'add' vs 'list' actions; it adds marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool queues changes for human review or lists pending items, with specific verb-resource and differentiation from siblings like 'cannot resolve human review' and 'never blocks deterministic lanes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (queue/list for dashboard) and when not to (approval/sludge is dashboard-only, does not block lanes), providing clear context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask-once gate. Confirms the task before any loop runs. If the task is underspecified, returns one brief explanation plus a few short questions once (goal; PATH — improve an existing loop / discover-or-find a loop, optionally scouting a public loop library / mine your whole history; the loop or domain to start from; corpus scope — whole history or a set number of loops, and best-first vs in-order; what "better" means; any task-specific hard limit; and a deeper-explanation offer); call again with { answers } to begin. It never asks the operator to choose the model, promotion mode, benchmark policy, deterministic-vs-subjective routing, or the standing guarantees — the supervisor decides those from the task. Stores every user message locally with a sha256 hash. After initialization it does not ask again or mark the campaign complete; the operator remains the stop condition and the dashboard stays available.
| Name | Required | Description | Default |
|---|---|---|---|
| task | No | what to improve/build | |
| model | No | frontier route; defaults to claude-opus-4-8 | |
| runId | No | reuse to continue a run; omit to create one | |
| config | No | { failurePatience(10-15), comparisonRule, promotion:{...}, mode } | |
| answers | No | answers to the ask-once questions | |
| userMessages | No | verbatim operator messages — stored + hashed for the hook | |
| acceptanceCriteria | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: stores messages with sha256 hash, asks once, never asks again after initialization, operator remains stop condition, dashboard stays available. This is comprehensive but could mention idempotency or side effects more explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a concise summary ('Ask-once gate') but then expands into a dense paragraph. While it is informative, the length could be slightly reduced by separating key points. Still, it remains focused and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, nested objects, no output schema, and many siblings, the description provides enough context for usage. It explains the initialization flow, constraints, and operator involvement. Lacks details on return values or state persistence, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 86%, so baseline is 3. The description adds context (e.g., 'answers' are responses to ask-once questions, 'userMessages' stored and hashed), but the schema already covers most parameters. Additional value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ask-once gate. Confirms the task before any loop runs.' It explains the interaction flow (returns questions, then call again with answers), which distinguishes it from sibling tools like loop_start or continue_run that handle later stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (before a loop runs) and clarifies what the tool will not ask (model, promotion mode, etc.), guiding the agent on what inputs are relevant. While it does not explicitly name alternatives, the context of the workflow is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every loop available to this local MCP: the mandated hash-locked loops plus any custom loops you registered with loop_register (id, title, trigger, sha256, line count, phase-gated section count, origin). No full bodies.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | No | optional; only used to journal |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the scope ('available to this local MCP'), the fields returned (id, title, etc.), and a key behavioral trait ('No full bodies'). This provides useful context beyond a simple 'list', though it does not cover authorization or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the core action and details the output fields, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional param, no output schema), the description is complete: it defines the return fields, clarifies the exclusion of bodies, and distinguishes mandated vs custom loops, leaving no major gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one optional parameter (runId) described as 'optional; only used to journal'. The tool description does not add meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('every loop available to this local MCP'), and distinguishes between 'mandated hash-locked loops' and 'custom loops you registered with loop_register'. It also lists the fields returned and clarifies that no full bodies are included, fully differentiating it from siblings like loop_register.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used to get an overview of all available loops, but it does not explicitly state when to use it versus alternatives (e.g., loop_next for stepping through loops). There is no 'when not to use' or mention of prerequisites, leaving usage interpretation to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of request_next_phase.
| Name | Required | Description | Default |
|---|---|---|---|
| loop | No | ||
| runId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed. The description does not mention side effects, permissions, rate limits, or any other behavioral aspects. With no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified. It provides only an alias reference without substantive content, sacrificing usefulness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not cover output, behavior, or parameter details. For a tool with two parameters and no output schema, the description is incomplete and does not enable correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the input schema. Neither 'loop' nor 'runId' are explained, and schema descriptions are absent. The tool fails to clarify parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Alias of request_next_phase,' which does not directly state what the tool does. It relies on the user knowing another tool's purpose, making the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use loop_next vs request_next_phase or other siblings. The description only indicates they are aliases without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add YOUR OWN loop to this machine's local MCP. Pass the full loop text as content; the MCP hashes it (sha256, write-once per version), assigns a safe id, splits it into phase-gated sections, and persists it locally. Stream it afterward with loop_start { loop:"" } exactly like the mandated loops. Cannot overwrite the hash-locked Strip Miner / Loop-de-loop. Nothing leaves your machine.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | safe lowercase id (no slashes/spaces); must not collide with a mandated loop | |
| role | No | ||
| runId | No | optional; only used to journal the registration | |
| title | No | ||
| content | Yes | the full loop text (headers or paragraph breaks become streamable phases) | |
| trigger | No | e.g. "/loop my-loop" | |
| overwrite | No | replace an existing custom loop of the same id with a new local version |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: sha256 hashing with write-once versioning, safe id assignment, phase-gated splitting, local persistence, and the inability to overwrite specific mandated loops. It also assures data stays local, covering safety and privacy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with the main action, and every sentence adds essential information without redundancy. It is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the registration process, including hashing, storage, and streaming after registration. It lacks details on return values or error handling, but the output schema is absent. For a registration tool, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, so baseline is 3. The description adds value by explaining how parameters like 'content' and 'id' are used in the process, though it does not enumerate each parameter. This provides helpful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' (register) and the resource 'YOUR loop to this machine's local MCP'. It details specific behaviors like hashing, id assignment, and phase splitting, and distinguishes from mandated loops, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (to add your own loop) and what not to do (cannot overwrite mandated loops). It also hints at streaming with loop_start, though it doesn't comprehensively compare with all sibling tools like loop_library. Overall, usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Begin phase-gated streaming of a bundled or custom local loop. Opens/activates the supervisor lane for that loop. Use "strip-miner" (The Strip Miner Loop / cross-agent source miner, 345 lines), "loop-de-loop" (Loop 2, the improvement loop, 75 lines), or any id registered with loop_register. Returns ONLY section 0; the full loop stays inside the supervisor.
| Name | Required | Description | Default |
|---|---|---|---|
| loop | Yes | strip-miner, loop-de-loop, or a custom loop id from loop_library | |
| runId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description describes key behavior: activating the supervisor lane and returning only section 0. It does not detail side effects, idempotency, or state changes, but the disclosed behavior is sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences with no wasted words. It front-loads the main action, then provides examples and return behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the main operation and return behavior, it does not explain the role of 'runId' or how this tool fits with siblings like loop_next. Given two required params and no output schema, the description is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: 'loop' has a description which the tool's description reinforces, but 'runId' lacks any description in schema or description. The description adds moderate value for 'loop' but does not fully compensate for the missing runId context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool begins phase-gated streaming and opens/activates the supervisor lane for a loop. It specifies valid loop values like 'strip-miner' and 'loop-de-loop', distinguishing it from siblings like loop_next or loop_register.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides examples of when to use the tool (e.g., 'Use strip-miner...') but does not explicitly compare with alternatives like loop_next or loop_register. It implies usage context but lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record lightweight evidence for the current phase (what you actually did/observed). Attach { loop, phase } to satisfy the phase gate and unlock the next section.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| loop | No | ||
| phase | No | ||
| runId | Yes | ||
| summary | Yes | ||
| sourceRef | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It reveals that the tool records lightweight evidence and is tied to phase gating, but does not disclose idempotency, side effects (e.g., whether it appends or overwrites), or what happens if called multiple times. Adequate but could be more detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence states purpose, second gives usage instruction. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple record tool with no output schema and no annotations, the description covers core purpose, key parameters, and the phase gate context. It lacks return value details and behavior on repeated calls, but is mostly complete given the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 6 parameters, the description explicitly mentions 'loop' and 'phase' and implies 'runId' and 'summary' are needed. It does not explain 'kind' or 'sourceRef', leaving gaps. Adds meaning but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Record' and resource 'evidence' in the context of the current phase. It also adds outcome ('unlock the next section'), distinguishing it from siblings like 'artifact_record'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains it is for recording evidence to satisfy a phase gate and unlock the next section, providing clear context. It does not explicitly state when not to use or name alternatives, but the context is sufficient for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request promotion of a hypothesis to internal champion. Requires a tool-measured, reverified full test on the frozen benchmark that moves the quality/cost frontier past threshold. Old green unit tests without a score matrix, model-reported metrics, or below-threshold results are BLOCKED. Never overwrites the operator’s canonical loop file.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | ||
| hypothesisId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses key behaviors: requires tool-measured reverified full test, blocks non-conforming results, and never overwrites canonical loop file. Could add details on idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding meaningful constraint or action. No wasted words, front-loaded with purpose and key requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what the tool does and its constraints well, but lacks parameter explanation and return behavior. No output schema; description does not mention what the agent gets back (e.g., success/failure, new champion ID).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage; description does not explain runId or hypothesisId beyond names. With 0% coverage, description should define or provide context for parameters, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Request promotion of a hypothesis to internal champion' with specific verb and resource, and distinguishes from sibling tools like 'loop_next' and 'reverify_run' by detailing unique conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use (hypothesis meeting strict criteria) and explicitly blocks old green unit tests without required metrics. Does not mention alternatives like 'reverify_run' or 'test_hypothesis' but context implies sequential use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register 3–5 challenger hypotheses, each on a frontier route. Requires baseline hash-lock + frozen benchmark + measured baseline bar (benchmark-first). Rejects <3 or >5, and any haiku/mini/nano/lite/prior-gen route.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | ||
| hypotheses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes what the tool requires and rejects, but does not mention side effects, idempotency, or whether it is read-only or destructive. Partial disclosure is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the purpose and then adding constraints. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the complexity of the input schema (array of objects with multiple fields), the description omits parameter details, return value, and error handling beyond rejections. It lacks completeness for a tool with many siblings and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It mentions constraints on hypotheses (frontier routes, model exclusions) but does not explain the meaning of fields like 'tradeoff', 'falsifier', or 'operation' within the hypothesis object. The runId parameter is completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'register', the resource 'challenger hypotheses', and includes constraints on number (3–5) and route type. However, it does not differentiate from sibling tools like 'test_hypothesis' that also involve hypotheses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists prerequisites ('baseline hash-lock + frozen benchmark + measured baseline bar') and rejection conditions ('<3 or >5, any haiku/mini/nano/lite/prior-gen route'), providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a reproducible markdown report (baseline lock, frozen benchmark, score matrix, promotions, failure patience, campaign state) to the run dir.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | ||
| format | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must fully disclose behavior. It says 'write' but omits side effects: does it overwrite? require permissions? fail silently? What is the run dir and what happens if it doesn't exist?
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, but the list of components is dense and could be clearer with bullet points or broken into separate sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema and annotations; does not explain 'run dir' or the effect of format. For a tool with 24 siblings, this is insufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description does not explain either 'runId' or 'format'. The report contents are listed, but how parameters influence output is absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Write') and resource ('reproducible markdown report'), and lists concrete components (baseline lock, frozen benchmark, etc.), clearly distinguishing it from siblings like 'report_saturation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. the many siblings. Does not mention prerequisites, exclusions, or context like whether it is for final export vs. intermediate reporting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tell the supervisor the current lane (e.g. the Strip Miner) has reached evidence-backed saturation. The supervisor AUTO-TRANSITIONS to the next lane (Strip Miner → Loop-de-loop, or the next improvement branch). It never pauses, awaits the operator, or treats "no re-mining warranted" as terminal — saturation is a pivot. The operator is the only stop condition.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | ||
| evidence | No | the saturation evidence (batches that changed nothing material) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It clearly explains that the supervisor auto-transitions, never pauses, awaits the operator only for stop conditions, and treats saturation as a pivot. This provides good context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the main purpose. Each sentence adds useful context (auto-transition behavior, no pausing, operator as stop condition). It could be slightly more concise but is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's effect and behavior well, but it does not mention return values or side effects (e.g., confirmation of saturation report). Given the tool's complexity and lack of output schema, more detail on what happens after reporting would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (evidence has description, runId does not). The description mentions 'evidence-backed saturation' but does not add specifics about the runId or evidence parameter format or constraints. It does not compensate for the missing runId description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: informing the supervisor that a lane has reached evidence-backed saturation. It uses specific verbs and resources ('Tell the supervisor...') and implicitly distinguishes from siblings like loop_next by focusing on the saturation trigger. However, it does not explicitly differentiate from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when evidence-backed saturation is reached) and describes behavioral consequences (auto-transition). However, it lacks explicit guidance on when not to use this tool versus alternatives (e.g., reverify_run, loop_next) and does not state prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stream the next loop section. BLOCKED (PHASE_SKIP) unless the current section already has recorded evidence. Prevents 300+ lines collapsing into the model before real decisions.
| Name | Required | Description | Default |
|---|---|---|---|
| loop | No | ||
| runId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses a blocking condition and rationale (prevents 300+ lines collapsing), but lacks detail on side effects, required permissions, or return format. The behavioral information is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. It front-loads the action and provides a constraint. No wasted words, though the second sentence could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, low schema coverage, and relatively complex behavior, the description is insufficient. It offers a high-level purpose and one constraint, but omits parameter explanations, error conditions, and return values. The agent cannot fully understand tool invocation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain either parameter. The agent gets no guidance on what 'runId' or 'loop' mean, how they affect behavior, or valid values. This is a critical gap for a tool with undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool streams the next loop section and provides a blocking condition. The verb 'stream' is specific, and the mention of 'BLOCKED (PHASE_SKIP)' clarifies the tool's behavior. However, it does not explicitly distinguish from sibling 'loop_next', so it loses a point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when the tool is blocked (unless current section has recorded evidence). This gives a usage condition but does not explicitly state alternatives or when not to use the tool. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deep re-verification: re-hash every raw artifact behind a full test and confirm the claimed metrics reproduce. Promotion is blocked until this passes (anti benchmark-gaming / baseline-tampering).
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | ||
| testId | No | ||
| hypothesisId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes re-hashing artifacts and metric reproduction, and notes the consequence of blocking promotion. It does not mention authorization, rate limits, or potential side effects beyond verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the key term 'Deep re-verification' and efficiently convey purpose and consequence without extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3 parameters and no output schema, the description fails to explain how parameters relate to the tool's operation. It does not define runId, testId, or hypothesisId, leaving the agent without guidance on what values to provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters with 0% description coverage, and the description does not explain any parameters. The agent must infer meaning from parameter names only (runId, testId, hypothesisId), which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs deep re-verification by re-hashing raw artifacts and confirming metrics reproduce. It distinguishes from siblings like benchmark_run or test_hypothesis by focusing on verification rather than initial execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when promotion is needed after a test, noting that promotion is blocked until this passes. It provides context for anti-benchmark-gaming but does not explicitly exclude when not to use or list alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AUTONOMOUS SUPERVISOR (opt-in: SUPER_LOOP_ALLOW_EXEC=1). One call drives the whole campaign itself — intake → work the target queue (mine → improve) → for each improve target: hash-lock baseline → freeze benchmark → measure the bar on a real worker → FullTestBatches (3-5 frontier workers, each output VALIDATED through the enforcement boundary) → supervisor delta → reverify → promote (bank a Stone) → advance/retire → re-mine — and keeps going until the operator stop-file. Worker output is never trusted: summary-only / early-stop / fake-metric / self-promote / phase-skip / copied-public are rejected and re-entered, and invalid batches do not count toward retirement. maxBatches bounds the in-call MCP run (a safety cap, NOT completion); the standalone super-loop-run CLI runs it until the stop-file. Returns the exact string MISSING_FULL_PRIVATE_LOOPS if a full private loop is absent.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | ||
| config | Yes | { task, routes:[3-5 frontier], benchmark:{name,taskValueDimensions,resourceDimensions,cases,oracle}, targets:[{kind:"mine"|"improve", loop?, baselineContent?, benchmark?, routes?}], noImprovePolicy?(default 30), remineOnEmpty? } | |
| stopFile | No | path whose existence stops the campaign — the operator stop signal | |
| maxBatches | No | safety cap on valid FullTestBatches for this in-call run (default 3); not a completion state |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: the complete workflow, trust model (worker output never trusted, rejection reasons), safety cap (maxBatches), and a specific return value for missing private loops. This is comprehensive for a complex tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense with information and front-loads the key supervisor role and opt-in requirement. While it could be more structured (e.g., bullet points), it efficiently communicates a complex process in a single paragraph without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity and no output schema, the description covers workflow, trust model, and a specific error return. However, it lacks detail on successful return format or other possible error states, which is a gap for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 3 of 4 parameters with descriptions. The tool description adds meaningful context beyond schema, e.g., warning that maxBatches is a safety cap not completion, and explaining stopFile as operator stop signal. However, it does not detail runId or the nested config structure further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it drives a full campaign autonomously, listing the detailed pipeline steps. It distinguishes from sibling tools like loop_next or reverify_run, which are individual steps, and explicitly mentions it's an 'AUTONOMOUS SUPERVISOR'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions opt-in environment variable (SUPER_LOOP_ALLOW_EXEC=1) as a prerequisite and contrasts with the standalone CLI. Implicitly suggests use when full automation is desired, but does not explicitly state when not to use or list alternatives beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record ONE full test of a hypothesis = 3–5 frontier agents that actually ran the loop end-to-end. Every agent run must carry a measurementRef (tool-measured). Aggregates vs the frozen baseline bar; a no-improvement run is NO_IMPROVEMENT, never "perfect", and bumps the failure counter.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | ||
| fullTest | Yes | ||
| hypothesisId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral rules: a no-improvement run must be recorded as NO_IMPROVEMENT (not 'perfect'), and failure counter is bumped. It also requires measurementRef. Without annotations, this provides important behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the tool's purpose. It is efficient but could benefit from clearer structure or bullet points for parameter guidelines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description partially explains the test recording process but lacks details on return values, error handling, or how to properly structure the fullTest object. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the three required parameters (runId, hypothesisId, fullTest) beyond mentioning measurementRef. It adds some context about agentRuns but insufficiently compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records a 'full test of a hypothesis' involving 3-5 frontier agents. It adds specificity about agent runs requiring measurementRef. However, it doesn't explicitly differentiate from sibling tools like 'execute_full_test' or 'run_campaign', so purpose is clear but not uniquely distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a full test is completed but does not provide explicit guidance on when to use this versus alternatives like loop_next or execute_full_test. No 'when not to use' or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the always-available local dashboard.html (score matrix, phase progress, failure patience, Approve/Sludge, and the stop-condition notice). Human review happens only here; deterministic lanes do not wait on it.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes a read-only render operation, but tool name suggests write/update, creating inconsistency. Fails to disclose side effects, auth needs, or rate limits. The conflicting name undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys the main action and contents, but could be more structured. The list of dashboard components is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and one required parameter, the description fails to explain the runId parameter, and the name-action inconsistency adds confusion. The tool definition is insufficient for correct agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'runId' has no description in schema (0% coverage), and the description does not mention it at all, providing no guidance on its meaning or how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it renders the local dashboard.html with specific contents like score matrix and phase progress, and implies a distinct role for human review. However, the tool name 'update_dashboard' contradicts the 'Render' verb, causing potential confusion about the tool's action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indirectly says 'human review happens only here; deterministic lanes do not wait on it', suggesting use when human review is needed, but does not explicitly state when to use this tool versus sibling tools like human_review_request or loop_next, nor mentions when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0artifact_recordbenchmark_proposebenchmark_runbenchmark_selectcampaign_statuscontinue_runcycle_decision_requestexecute_full_testhost_capability_preflighthost_runtime_detecthuman_review_requestinitialize_loop_runloop_libraryloop_nextloop_registerloop_startobservation_recordpromotion_requestregister_hypothesesreport_exportreport_saturationrequest_next_phasereverify_runrun_campaigntest_hypothesisupdate_dashboardScored across 26 tools
Most tools have distinct purposes, with clear descriptions. The only ambiguity is 'loop_next' being an alias of 'request_next_phase', which could cause confusion. Otherwise, tools like 'benchmark_propose', 'benchmark_run', and 'benchmark_select' are well-differentiated.
All tools use lowercase and underscores, but the verb/noun order is inconsistent: some are verb_noun (e.g., 'run_campaign'), some are noun_verb (e.g., 'artifact_record'), and a few are noun_noun (e.g., 'loop_library'). Despite this, the names are still readable and predictable.
With 26 tools, the set is relatively large but appropriate for the complex domain of loop-based benchmarking and hypothesis testing. Each tool serves a specific function within the lifecycle, and no tools seem superfluous.
The tool surface covers the entire workflow from initialization, loop management, benchmarking, hypothesis registration, testing, promotion, reporting, to saturation detection and campaign execution. Host detection and human review are also included, leaving no obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Deterministic AI code review, with an audit record. Governance inside the agent loop.
ADHD system of record for agents: tasks, goals, loops, calendar, focus stats.
Watchdog for unattended AI agents: alerts, evidence checks and a verifiable proof per run.
AI work orchestration for plans, tasks, teams, and coding-agent dispatch.
