super-loop-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
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.
Naming Consistency4/5
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.
Tool Count4/5
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.
Completeness5/5
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.
Average 3.7/5 across 26 of 26 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as side effects, permissions, or state changes. The alias reference does not compensate for missing behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise but at the cost of under-specification. A single sentence that adds little value beyond the name. Every sentence should earn its place; this one does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, missing annotations, and zero parameter descriptions, the tool description is completely inadequate for guiding proper invocation. It fails to provide essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain the parameters 'loop' and 'runId'. The agent has no information about their meaning or expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it is an alias of request_next_phase, but does not explain what that tool does. The purpose is vague and relies on prior knowledge of the aliased tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only states it's an alias, implying interchangeability with request_next_phase, but offers no context or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'write' implying mutation, but does not disclose side effects (e.g., overwriting files), required permissions, or any destructive potential. This is insufficient for safe tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that lists many report components, which is somewhat dense. It could be more concise by omitting internal details, but it is not overly verbose. Scores in the middle range.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and zero parameter documentation, the description does not adequately inform the agent. It fails to explain the report's structure, output location (besides 'run dir'), or any return value, leaving significant ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain either parameter. The agent must infer that 'runId' identifies a run and 'format' specifies output format, but no permissible values or semantics are provided. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes a reproducible markdown report containing specific components (baseline lock, frozen benchmark, score matrix, etc.) to a run directory. This is a specific verb+resource combination that distinguishes 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites, when not to use it, or which sibling tools might be preferable for different reporting needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. Lacks details on read-only nature, error handling, permissions, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with key information front-loaded. Could be slightly more structured but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing details on return value, error conditions, prerequisites, and parameter explanation. Incomplete for a tool with no output schema and sparse annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description does not mention the single parameter 'runId', leaving its purpose and usage entirely to the schema, which has 0% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'render' and resource 'dashboard.html', listing specific components. However, the tool name 'update_dashboard' suggests a write operation, causing potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that human review happens only here, implying when to use it. Does not explicitly state when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly marks it as 'Read-only', which is a key behavioral trait. It also notes that 'Pending review never blocks the campaign', providing useful insight. However, it does not cover other behavioral aspects like side effects, authentication, or rate limits, which are more important given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that front-loads the key purpose. It efficiently communicates multiple status components, though domain-specific jargon may hinder clarity for some agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers the main status elements. However, it lacks explanation of the return format, error conditions, or how the output is structured, leaving moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 mention the single parameter 'runId'. The agent gets no guidance on what value to provide or its format, making it difficult to use correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 enumerates specific components (lane/target queue, auto-transitions, etc.), making the tool's purpose clear and distinct from siblings that perform actions like 'run_campaign' or 'continue_run'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. It does not mention context, prerequisites, or when not to use it. The description only states what it does without helping the agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Record lightweight evidence' without disclosing side effects (e.g., whether it updates existing records, requires permissions, or affects state). Behavioral traits are largely missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose, and contains no fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is too brief. It does not cover return values, error conditions, or detailed parameter usage, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only mentions attaching loop and phase, leaving kind, runId, summary, sourceRef unexplained. It adds minimal value beyond the schema for the majority of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for 'Record lightweight evidence for the current phase,' which is specific and actionable. It mentions attaching loop and phase to satisfy a phase gate, adding context. However, it doesn't explicitly differentiate from sibling tool 'artifact_record', which might record artifacts vs. observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage during a phase to record observations, and that attaching loop/phase unlocks the next section. It provides some context but no explicit guidance on when not to use or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 that runs must have measurementRef, aggregation against baseline, and that no-improvement is NO_IMPROVEMENT (bumping failure counter). However, it does not disclose mutability, side effects, or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose. It is not verbose, though breaking into smaller sentences could improve readability. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested objects, 3 required fields) and no output schema, the description is incomplete. It omits parameter details, return values, and usage context for the nested agentRuns array. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds minimal meaning beyond parameter names. It hints at measurementRef and aggregation but does not explain runId, hypothesisId, or fullTest structure. The description fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 with 3-5 frontier agents, specifying the required measurementRef and aggregation behavior. It distinguishes from siblings like 'execute_full_test' by emphasizing the recording aspect, though not explicitly differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after agents run the loop end-to-end and mentions aggregation rules, but does not explicitly state when not to use or compare with alternatives like 'execute_full_test'. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses re-hashing and metric confirmation, but omits whether operations are read-only, required permissions, or failure consequences. Partially informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with clear purpose and context, front-loaded and efficient. Lacks parameter descriptions, but overall structure is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, description is incomplete. Does not explain return values or error conditions, leaving significant gaps for a verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description only mentions 'full test' and 'hypothesis' indirectly. Does not explain runId (required), testId, or hypothesisId. Fails to add meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool re-hashes raw artifacts behind a full test to confirm metrics reproduce, with a specific purpose of blocking promotion to prevent benchmark gaming. It distinguishes itself from siblings like benchmark_run or test_hypothesis by focusing on verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when promotion is blocked or for anti-gaming, but does not explicitly state when to use vs alternatives like execute_full_test or test_hypothesis. Lacks exclusions or explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses the requirement for a recorded raw artifact and that model self-report doesn't set the bar. Missing details on side effects, idempotency, error handling, or whether it overwrites existing runs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with no waste. Front-loaded with main purpose, then additional constraints. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a tool with 3 required params and no output schema. Explains frozen benchmark concept, baseline role, and measurementRef requirement. However, lacks details on return value, success behavior, or error cases, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only arm described). Description adds meaning by specifying measurementRef is a recorded raw artifact, and arm is baseline or hypothesis id, but runId remains unexplained. Some value beyond schema, but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool records a tool-measured run of an arm in a frozen benchmark, and specifies that the baseline arm sets the bar. It distinguishes from sibling tools like artifact_record and benchmark_propose by focusing on measurement runs, but does not explicitly differentiate from other benchmark-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that measurementRef must be a recorded raw artifact and model self-report never sets the bar, implying when not to use. However, lacks explicit when-to-use/when-not-to-use guidance or alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool cannot resolve and is dashboard-only, and that it never blocks lanes. However, it lacks details on side effects, auth requirements, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loading the main purpose and key constraints. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description covers core constraints but omits return format, pagination for list, and behavior when queuing. Given sibling tools, more context would help, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 67% of parameters with descriptions (notes, action, decision, reviewId). The description reiterates the 'list' vs 'add' actions but adds little beyond the schema. It does not explain nested 'item' object fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queues changes for the operator's Approve/Sludge dashboard or lists pending items. It distinguishes from resolve actions, but does not explicitly differentiate from sibling tools like update_dashboard or cycle_decision_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use (add to dashboard or list) and when not to (cannot resolve). It also notes that it never blocks deterministic lanes. However, it does not mention alternatives or specific sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool returns only section 0 and the full loop stays in the supervisor. With no annotations provided, the description carries full burden but omits details like side effects, idempotency, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with primary action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and return value, but missing safety context (read-only or destructive), error conditions, and prerequisites. Moderate complexity warrants more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains the 'loop' parameter with examples and references loop_library, adding meaning beyond the schema. However, the 'runId' parameter is not elaborated. With 50% schema coverage, the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('begin', 'opens/activates') and resource ('streaming of bundled or custom local loop'). Mentions specific loop IDs and distinguishes from related tools like loop_register and loop_library. However, it does not explicitly differentiate from sibling tools like loop_next.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides examples of when to use specific loop IDs ('strip-miner', 'loop-de-loop'), implying context for use. However, it does not state when not to use this tool or compare with alternatives like loop_next or cycle_decision_request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals that the tool can be blocked and explains why (prevents collapsing lines). But it omits details about return behavior, error handling, or what happens when blocked.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action, and adds a critical condition without wasted words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% parameter description coverage, the description fails to explain return values, error scenarios, or parameter details. The blocking condition is noted but not elaborated, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation for the parameters 'loop' or 'runId'. The agent receives no guidance on their meaning or format, which is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it streams the next loop section and includes a blocking condition (requires evidence), which distinguishes it from siblings like loop_next or loop_start. It is specific about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool is 'BLOCKED (PHASE_SKIP) unless the current section already has recorded evidence,' providing a clear precondition for use. However, it does not mention when to avoid using it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adds behavioral insights like 'reasoning alone is never proof' and lists allowed intents. However, it does not disclose side effects, auth requirements, or what happens upon acceptance/rejection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a list) and front-loaded with the core purpose. However, the list of intents could be formatted more clearly, and some sentences are packed with information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is incomplete. It explains the high-level purpose but lacks parameter details, return value, and error states.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain any parameter. It mentions allowed intents but does not map them to the 'intent' parameter or explain other parameters like runId, loop, rationale, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this is a supervisor decision hook for approving transition packets, with specific allowed intents. It uses specific verbs ('proposes', 'accepted') and distinguishes itself from other tools by being the only one where supervisor acceptance is required.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for supervisor decisions) and explicitly states that completion/stop-style intents are refused, indicating when not to use. It does not name alternative tools but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 behavioral constraints like the rejection criteria and the prerequisite of a 'benchmark-first' state, but lacks details on side effects (e.g., whether it modifies state), required permissions, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that conveys the core purpose, constraints, and prerequisites without any extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the input schema (nested objects with many fields) and no output schema, the description only partially informs the agent. It covers usage constraints but fails to explain the structure of the `hypotheses` objects, which is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain any parameters. The `runId` and `hypotheses` array fields, including their nested properties, remain completely undocumented, leaving the agent without guidance on how to populate them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Register' and the resource 'challenger hypotheses', specifying the quantity range (3–5) and the constraint 'frontier route'. This differentiates it from sibling tools like 'test_hypothesis' which likely handles individual hypotheses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites ('Requires baseline hash-lock + frozen benchmark + measured baseline bar') and rejection conditions ('Rejects <3 or >5, and any haiku/mini/nano/lite/prior-gen route'). However, it does not mention alternatives or when not to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It explicitly states that the supervisor auto-transitions, never pauses, and that the operator is the only stop condition. This provides clear behavioral expectations beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with three sentences, front-loading the main action. It is clear and efficient, though the second and third sentences add important behavioral context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 (auto-transition) and key behavioral traits, but does not mention return values or confirmation of the report. Since there is no output schema, the description should ideally address what the agent can expect after invoking the tool, which is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context to the parameters: it explains that 'runId' identifies the lane (e.g., Strip Miner) and that 'evidence' is the saturation evidence. This supplements the schema, which only describes 'evidence' as 'batches that changed nothing material'. However, it does not specify constraints or formats for 'runId'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: reporting saturation to trigger an automatic lane transition. It specifies the action ('tell the supervisor') and the context ('current lane has reached evidence-backed saturation'), which distinguishes it from termination or pause actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (when saturation is reached) and what the supervisor does next (auto-transition). It clarifies that this is not a terminal action, but does not compare with sibling tools like 'cycle_decision_request' or 'request_next_phase', missing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses key behaviors: role='baseline' is write-once (tampering refused), measurement includes tokenCost/quality for measurementRef, and sourcePath is disabled. However, it omits error behavior, idempotency, or mutation effects. Good but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long with no fluff. Every sentence adds critical information (purpose, role behavior, sourcePath constraint, measurement structure). Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters, no output schema, and low schema coverage, the description covers only key aspects. It does not explain the return value or behavior for missing parameters. Adequate but incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (2 of 10 parameters have descriptions). The description adds meaning for role (explains values), sourcePath (disabled), and measurement (expected fields). It compensates partially but leaves many parameters (loop, name, phase, runId, newEpoch, rationale) unexplained. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 further specifies the behavior for role='baseline' (hash-lock, write-once) and the measurement parameter for reverifiable measurementRef. This distinguishes it from sibling tools like observation_record or loop_register, which handle different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context (e.g., 'sourcePath reads are disabled; pass explicit content') but does not explicitly state when to use this tool over siblings. It implies usage for storing artifacts with specific roles, but lacks when-not scenarios or alternatives. Moderate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden. It discloses a rejection behavior for proposals missing required dimensions or cases ('or it is rejected as a hand-waved benchmark'). However, it does not detail side effects, auth needs, or rate limits, offering limited behavioral context beyond validation rules.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with two sentences. The first sentence immediately states the action and source, and the second provides critical constraints. No superfluous information, each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and rejection criteria but omits details on the runId parameter, other fields in the benchmarks object, and the return value (no output schema). For a tool with complex nested input and no output schema, more context is needed for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explains the meaning of taskValueDimensions, resourceDimensions, and cases by specifying they are required. However, other fields like oracle, qualityScale, comparisonRule are not covered, leaving some parameters semantically underdescribed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool proposes benchmark scorecards built from real prior uses/failures, with specific verb 'propose' and resource 'benchmark scorecards'. It distinguishes from sibling tools like benchmark_run or benchmark_select by emphasizing the proposal of new benchmarks with required elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating benchmarks based on prior data and sets criteria for valid proposals, but does not explicitly state when to use versus alternatives or provide when-not scenarios. Usage guidance is implied through the required components, but no direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool blocks certain inputs and never overwrites the operator's canonical loop file. However, it does not describe side effects of a successful promotion, such as state changes or notifications, which would be helpful for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences) and front-loaded with purpose. Every sentence adds value (purpose, conditions, behavioral note). Minor room for improvement: structuring conditions more clearly could aid readability, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 2 required parameters with zero schema coverage, the description is incomplete. It lacks parameter explanations and return value information. The agent cannot confidently invoke the tool without understanding what 'runId' and 'hypothesisId' refer to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). The description does not explain the meaning or expected format of 'runId' or 'hypothesisId', leaving the agent to guess. With low schema coverage, the description should compensate but fails to provide parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Request promotion of a hypothesis to internal champion.' The verb 'request' and resource 'promotion of a hypothesis' are specific. It distinguishes from siblings like 'test_hypothesis' (testing) and 'benchmark_propose' (proposing) by focusing on promotion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit conditions for use: requires a tool-measured, reverified full test on the frozen benchmark that moves the quality/cost frontier past threshold. It also states what is blocked (old green unit tests without score matrix, model-reported metrics, below-threshold results). This gives 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the irreversible nature, prerequisite, and change procedure. Could mention failure modes or confirmation behavior, but adequately covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. First sentence states core function, second adds important conditions. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers the essential action, prerequisites, and change process. Minor gaps about error conditions and return values, but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description does not explain individual parameters (runId, benchmarkId, newEpoch, rationale). Only rationale is indirectly mentioned for changes. The description fails to compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool freezes ONE proposed benchmark as an immutable scorecard, using a specific verb and resource. It distinguishes from siblings like benchmark_propose and benchmark_run by implying finalization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (baseline hash-locked) and consequences for changes (new epoch + rationale). It does not directly state when not to use, but the context of sibling tools suggests alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behavioral traits: never asks user, never marks campaign complete, does not clear continuation obligation. However, it does not mention any side effects, authorization needs, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and informative, but somewhat verbose. It front-loads purpose well, but could be more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description explains context, behavior, and constraints fairly well. It covers when to use and what to expect, but lacks details on return values or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, but the description adds minimal extra meaning for parameters. It explains that 'lane' is the next runnable lane and 'firstAction' is the concrete next tool/action, which mostly repeats the schema descriptions. It does not describe 'runId' or 'rationale', leaving them under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 improvement lane and first action, and specifies the contexts after which it is used (reports, dashboards, saturation findings, etc.). It differentiates from siblings by noting it never asks the user, never marks campaign complete, and does not clear continuation obligation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use the tool (after specific findings/advisories) and what it does not do (never asks user, never marks complete). It also implies that a real progress tool must run next, guiding the agent on follow-up actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses critical behavioral traits: execFile (no shell), allowlisted binaries, captura output and gate processing, blocking behavior without opt-in, and failure handling. However, it does not describe the return format for successful executions, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but somewhat lengthy. It is well-structured: front-loaded with the core purpose and opt-in requirement, followed by operational details and alternatives. Every sentence adds value, though some could be more succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not fully specify the return value for successful execution. It mentions blocking behavior but not the structure of success results. The reference to 'same gate as test_hypothesis' provides some context but is ambiguous. Overall, sufficient but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60% (3 of 5 parameters have descriptions). The tool description adds minimal new information beyond the schema: it mentions 'routes' must be allowlisted and 'prompt' is the task, but these are already in the schema. It does not explain 'runId' or 'hypothesisId'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it executes a full test by launching 3-5 allowlisted frontier workers via execFile, captures outputs, and processes them. It distinguishes itself from test_hypothesis by noting that it launches real workers and that without opt-in it blocks, directing to alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool is off by default and requires an environment variable opt-in. Provides clear guidance on when to use (with opt-in) and when to use alternatives (without opt-in, use artifact_record + test_hypothesis). Also clarifies that failed launches do not count toward retirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that the tool is read-only ('List'), defines the exact fields returned, and explicitly states that full loop bodies are not returned. This is transparent and sets accurate expectations for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that conveys the purpose, scope, fields, and limitations. Every word serves a purpose, and the key information is front-loaded: 'List every loop available to this local MCP'. The parenthetical list of fields is compact yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is fully complete. It covers functionality, content, and exclusions. The mention of 'hash-locked loops' and 'custom loops' provides necessary context about what 'every loop' means. No additional detail is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single optional parameter runId with a description ('only used to journal'), so baseline is 3. The tool description does not add any additional semantic meaning to this parameter beyond what the schema already provides. Given 100% schema coverage, no extra value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'every loop available to this local MCP'. It specifies what is included (mandated hash-locked loops and custom loops) and explicitly states what is not ('No full bodies'), leaving no ambiguity. This directly distinguishes it from sibling tools like loop_register (which creates) and loop_start (which executes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by mentioning custom loops registered with loop_register, implying its use for discovery. It explicitly states the output excludes full bodies, setting expectations. However, it does not include explicit when-not-to-use instructions or comparisons to other sibling tools like loop_next or loop_start, which would further enhance guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: hashing (sha256, write-once), id assignment, phase splitting, local persistence, and privacy (nothing leaves the machine). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the main action. Every sentence contributes essential information without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, no output schema), the description adequately covers the registration process, constraints, and next steps. It lacks explanation for optional params like role and trigger, but the schema provides basic descriptions for most. Overall, sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 71% (5 of 7 params described). The description adds value for 'content' by explaining how it becomes streamable phases, and reinforces 'id' constraints. Other optional params (role, title) are not elaborated, but schema covers most; thus the description enhances understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: adding a user's own loop to the local MCP. It specifies the action ('Add YOUR OWN loop'), the resource (local MCP), and differentiates from sibling tools like loop_start and loop_library by focusing on custom loops and referencing mandated loops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool (to register a custom loop) and implies that mandated loops do not need registration. It also advises to use loop_start afterward. However, it does not explicitly state when not to use it or provide alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It exhaustively discloses the pipeline steps, security measures (worker output never trusted, rejection of invalid batches), return value (MISSING_FULL_PRIVATE_LOOPS), opt-in requirement, and the role of maxBatches as an in-call safety cap. No behavioral contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence adds necessary detail for a complex tool. It is front-loaded with 'AUTONOMOUS SUPERVISOR' and uses bullet-like flow with arrows. Could be slightly more structured but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: pipeline steps, validation rules, safety cap, stop-file mechanism, return value, and opt-in requirement. No output schema exists, but the description fully compensates by explaining the only return string. Complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, and the description adds value by explaining the 'config' parameter's nested structure and clarifying 'stopFile' and 'maxBatches' semantics beyond the schema. However, 'runId' lacks both schema description and description text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool 'drives the whole campaign itself' and outlines the full pipeline. It distinguishes itself from sibling tools like 'campaign_status' and 'continue_run' by being the autonomous supervisor that handles intake, work, validation, and retirement until a stop-file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit opt-in condition (SUPER_LOOP_ALLOW_EXEC=1) and contrasts with the standalone CLI alternative. Explains maxBatches as a safety cap rather than completion. Does not directly compare to sibling tools but the autonomous nature is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![super-loop-mcp-merged MCP server](https://glama.ai/mcp/servers/alexalexalex222/super-loop-mcp-merged/badges/card.svg)](https://glama.ai/mcp/servers/alexalexalex222/super-loop-mcp-merged)

Score Badge

Copy to your README.md:

[![super-loop-mcp-merged MCP server](https://glama.ai/mcp/servers/alexalexalex222/super-loop-mcp-merged/badges/score.svg)](https://glama.ai/mcp/servers/alexalexalex222/super-loop-mcp-merged)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/alexalexalex222/super-loop-mcp-merged'

If you have feedback or need assistance with the MCP directory API, please join our Discord server