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
Tools are largely distinct, each serving a specific phase (e.g., benchmarking, hypothesis testing, campaign status). The only minor issue is 'loop_next' being an alias for 'request_next_phase', but this does not cause significant confusion.
Naming Consistency3/5
Naming patterns are mixed: some follow verb_noun (e.g., 'initialize_loop_run', 'register_hypotheses'), while others use noun_verb (e.g., 'loop_start', 'benchmark_propose') or compound nouns (e.g., 'promotion_request', 'campaign_status'). This inconsistency can make it harder for an agent to predict tool names.
Tool Count3/5
With 25 tools, the server is at the high end for a single MCP. While each tool serves a distinct role in the complex loop-based workflow, the count feels slightly heavy and could be streamlined by combining some related operations.
Completeness4/5
The tool set covers the entire campaign lifecycle: initialization, phase-gated loops, evidence recording, benchmarking, hypothesis testing, promotion, status, review, and export. Minor gaps exist (e.g., no tool to update or delete registered loops), but the core workflow is well-supported.
Average 3.7/5 across 25 of 25 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits 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 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.
Conciseness2/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose2/5
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.
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 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/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 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.
Purpose5/5
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.
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. 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters1/5
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.
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 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.
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. 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.
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 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/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 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.
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' 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.
Usage Guidelines3/5
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.
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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/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 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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
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 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.
Parameters3/5
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.
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: 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.
Usage Guidelines3/5
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.
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 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines3/5
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.
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 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/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 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines4/5
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.
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 behaviors: local storage with sha256 hash, no repeated questioning, operator remains stop condition, and dashboard stays available. It lacks explicit mention of error handling or idempotency, but covers the core safety and lifecycle traits.
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 dense paragraph with many clauses and parentheticals. While every sentence contributes information, the structure could be improved with bullet points or clearer separation of concerns for easier scanning.
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 tool's complexity—7 parameters, nested objects, and many sibling tools—the description adequately covers purpose, usage, behavioral nuances, and parameter context. It does not explain return values, but no output schema exists and the rules state that is not required.
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 86%, baseline 3. The description adds value by explaining the 'answers' parameter as responses to the ask-once questions and clarifies the role of 'task', 'userMessages', and 'runId' in the initialization flow. This goes beyond the 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 identifies the tool as an 'Ask-once gate' that confirms the task before loops run, and details the specific questions it asks. This distinguishes it from sibling tools like loop_start or loop_next 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 states when to call (first, before any loop) and to call again with answers to begin. It also clarifies what it never asks (model, promotion mode, etc.), providing implicit guidance on when not to expect those queries. However, it does not explicitly contrast with 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, 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it only performs filesystem stat, never executes, never probes arbitrary binaries, is not web/SOTA research, and does not verify 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?
The description is succinct (about 50 words), front-loaded with the main purpose, and every sentence adds necessary context (scope, safety, caveat). No redundancy.
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 preflight check tool with one optional parameter and no output schema, the description covers all needed aspects: purpose, method, limitations, and caveats. It is fully 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 coverage is 100% for the single parameter (runId), described as optional and for journaling. The description adds no extra parameter information, so 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 reports which known frontier-agent CLIs are installed on PATH. It uses specific verbs ('Local capability report') and resources, and distinguishes from siblings by focusing on static path checking.
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 gives implicit usage context (preflight check before using CLIs) and important caveats ('NEVER executes a command', 'Presence on PATH is not proof of working auth'). However, it does not explicitly contrast with sibling tools or provide alternatives.
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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

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 MCP server](https://glama.ai/mcp/servers/alexalexalex222/super-loop-mcp/badges/card.svg)](https://glama.ai/mcp/servers/alexalexalex222/super-loop-mcp)

Score Badge

Copy to your README.md:

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

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'

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