Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: parallel execution, scoring, best-effort budget cap, preservation of losers, evaluator cost exclusion, and return format. It covers edge cases like budget exhaustion and all-zero scores, and explains the search stamp recording.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear lead sentence, bullet points, and sections. It is thorough but not overly verbose; every sentence adds value. Minor conciseness could be improved by merging some explanations, but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given ten parameters, no schema description coverage, and an output schema that exists, the description covers all aspects: input semantics, behavioral quirks, return schema, error handling, and anti-patterns. It leaves no obvious gaps for an agent to understand when and how to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it does comprehensively. Every parameter is explained with context—e.g., evaluator must start with 'score:' or 'validate:', default values, and the effect of 'keep_losers' on preserving alternatives. This adds substantial meaning beyond the schema's basic type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Sample N candidates in parallel, score each, commit to the top-1.' It clearly distinguishes from sibling tools like 'par' and 'race' by explaining it's a search combinator with scoring, comparing to self-consistency/majority-vote.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit guidance on evaluator forms (score: vs validate:) and when to use each. It mentions an anti-pattern (expensive evaluator) and recommends using a governor instead. However, it does not explicitly contrast with all sibling tools like 'chain' or 'map', leaving some usage context implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes data flow (output as context) and that stages support sandbox fields, but lacks detail on error handling, resource usage, or execution semantics. With no annotations, more transparency would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences for purpose and a clear explanation of stages format. No fluff, front-loaded, efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers input semantics and pipeline behavior adequately. Missing edge cases but output schema exists, so return values not needed. Good for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'stages' is a string, but description clarifies it is a JSON array of stage objects and lists supported sandbox fields, adding significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool runs agents sequentially as a pipeline, and explains that each stage receives prior output as context. This distinguishes it from sibling tools like 'par' (parallel) and 'map_reduce'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for sequential processing, but no explicit guidance on when to use vs alternatives or when not to use. Could mention that 'par' is for parallel execution.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose all behavioral traits. It explains the effect on MCP access but does not address whether classification overwrites existing settings, if changes are reversible, or if there are authorization requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, with a clear first sentence stating purpose, followed by a usage example and parameter details. Every sentence adds value without redundancy or unnecessary fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, parameters, and usage context adequately. It does not explain the return value, but an output schema exists, so the agent can infer that. Minor missing detail: what happens if both allowed and denied lists are provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema by enumerating the classification levels (public, internal, confidential, restricted) and explaining that allowed_mcps and denied_mcps are JSON arrays of MCP names. The schema only shows types with no enums or descriptions, so the description fully compensates for the 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set' and the resource 'classification level on a ref', specifying that it controls MCP access. It distinguishes from siblings like 'encrypt' or 'wrap' by focusing on data sensitivity enforcement, which is unique among the listed tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides concrete examples of when to use the tool, such as marking legal documents as confidential and synthetic outputs as public. However, it does not explicitly mention when not to use it or compare to alternatives, but the sibling tools are not in the same domain.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses side effect: writes to output.md and returns path. With no annotations, this covers critical behavioral traits, though error conditions are omitted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise paragraphs: main action first, then args list. No wasted words, front-loaded with purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-param tool with an output schema, description covers purpose, side effect, and parameter usage completely. No missing critical aspects.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Provides crucial detail beyond schema: ref can be a JSON object with 'ref' field, and key_id must come from encrypt tool. Schema coverage was 0%, so description fully compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Decrypt an encrypted ref's text' with specific verb and resource. Distinguishes from sibling 'encrypt' tool by implying the inverse operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly requires key_id from encrypt tool as prerequisite. No explicit when-not-to-use or alternatives, but context is clear for a simple decryption task.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description explains that metadata stays visible, only text is encrypted, and a key_id is returned. It does not cover error conditions or auth details, but provides sufficient behavioral context for a simple tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with the core purpose, and structured with an 'Args' section. Every sentence adds information without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter and an output schema (not shown), the description explains input and outcome comprehensively. It covers encryption behavior, metadata visibility, and key usage, making it complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has no description for the 'ref' parameter (0% coverage). The description adds valuable semantics: it accepts a ref string like 'run_id/agent_id' or a JSON object with a 'ref' field, clarifying the input format.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool encrypts a ref's text payload and explains the effect (returns ref with key_id, only callers with key can decrypt). It distinguishes from the sibling tool 'decrypt' by implication.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for confidentiality of text content and mentions key-based access, but does not explicitly contrast with alternatives or provide 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears full burden. It discloses that validation runs in parallel on each ref, returns only valid results, and defines parameters. It does not mention side effects (likely none) or failure modes, but coverage is good.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly conciseness: two short paragraphs plus an Args list. Front-loaded with main purpose, then details, then parameters. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters and an output schema, the description adequately covers behavior (parallelism, return criterion) and parameter meanings. Minor gaps: no edge case handling (e.g., empty refs) but not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It provides a clear Args section explaining each parameter: refs (JSON array), declared_type (type name), model (default), timeout (default). This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool filters refs by type validation, keeping only those with a VALID verdict. It explicitly calls itself a 'type-gated composition primitive', making its purpose distinct from sibling tools like 'validate' or 'chain'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use (to filter valid refs) but does not explicitly compare to alternatives or state when not to use it. Given many sibling tools, more explicit guidance would improve usability.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavior. It mentions optional resolution of references, but does not explain error conditions, permissions, or return format beyond the output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: two sentences plus a bullet list, with no unnecessary words. Information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple getter with few parameters and an output schema, the description covers the core purpose and parameter semantics. It lacks guidance on when to use versus related tools, but is otherwise sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 0% schema description coverage, the description adds examples for 'name' and clarifies the effect of 'resolve_refs' (inline references, default true), which goes beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get a type definition by name' with a specific verb and resource, and distinguishes itself from siblings like 'list_type_registry' which lists all types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (e.g., when you need a single type definition) but does not explicitly state when to use this tool versus alternatives like 'list_type_registry' or 'validate'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the full burden of behavioral disclosure. It states the outcome (returns ref or error) but does not disclose side effects, permissions, or whether the operation is read-only. The mention of 'monadic condition' is vague. This leaves ambiguity about non-obvious behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (4 lines plus Args block) and well-structured. It provides essential information without unnecessary verbosity. The use of an Args section clearly delineates parameter explanations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, no annotations, output schema exists), the description covers purpose, parameters, and basic behavior. It mentions the output (ref or error) but does not detail the output schema structure. Still, this is sufficient for an agent to use the tool correctly in most scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the 'check' parameter's enum values explicitly and provides examples for 'value' (e.g., type name for validated). However, the description for 'ref' says 'string or JSON object' while the schema defines it as 'string', which creates a minor inconsistency.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it checks a monadic condition on a ref and returns the ref or an error. It names specific check types, which aids understanding. However, it does not explicitly differentiate from sibling tools like 'validate' or 'filter', which may have overlapping functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Use to enforce constraints before passing refs to downstream combinators.' This provides clear usage context. It does not mention when not to use or alternative tools, but the context is sufficient for basic guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description fully covers behavioral traits: concurrent execution, failure isolation, merging into a global leaderboard, default values for strategies (top_k, models, timeout), and detailed return structure (run_id, strategies, leaderboard, per-ref scoring trace).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is somewhat lengthy but well-structured: it starts with the core purpose, then explains the strategy dict in detail, followed by args and returns. Every sentence earns its place, though some sections (like the extensive strategy fields) could be slightly more compressed without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (orchestrating multiple strategies), the description is complete. It covers usage, parameter details, defaults, failure behavior, merging logic, and return format. The output schema exists but the description also explains the return structure, so no gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description compensates by exhaustively documenting the strategies parameter with required/optional fields, each field's meaning, and examples. It also explains max_parallel_strategies and top_k_global with defaults, adding all meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Run multiple (fetch → map → score) hunt strategies in parallel and merge.' It further explains it's a 'compound combinator' for parallelizing hunt framings, distinguishing it from sibling tools like run, map, or chain that operate on single sequences.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly indicates when to use this tool: 'makes run all the hunt framings at once tractable — rather than sequentially trying one hunt shape at a time.' It implies an alternative (sequential use) but does not explicitly list when not to use it. The parallel nature and failure isolation are well explained.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses the side effect of writing a debug report to output_dir/inspect.md. No annotations exist, so description carries full burden; additional details on read-only nature could improve score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise paragraphs with clear structure: first explains what the tool does, second gives usage guidance and parameter hint. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter tool with an output schema, the description fully covers input purpose, output side effect, and usage scenario. No gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds meaning to the 'ref' parameter beyond the schema by providing an example format 'run_id/agent_id'. With 0% schema coverage, this compensation is effective but still basic.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool inspects an agent's full execution state, listing specific components (partial output, stream log, files produced). This distinguishes it from sibling tools that execute or manage agents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use after a timeout, crash, or unexpected result to understand what happened', providing clear context for when to use this tool vs alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It thoroughly covers the iterative behavior, halting conditions (success threshold, patience, budget, wall time, max iterations), evaluator forms, and how prior attempts are injected. This is comprehensive and transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for general behavior, evaluator forms, and arguments. It is front-loaded with the main purpose. While somewhat lengthy, it earns its sentences given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 12 parameters and 1 required, the description covers all aspects: behavior, halting conditions, evaluator variants, parameter details, and return value structure (output schema exists). It is complete and leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the schema lacks parameter descriptions. The description compensates fully with detailed 'Args' section explaining each parameter, including defaults and behavior. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Iteratively refine an agent's output until an evaluator is satisfied.' It explains the iterative process and distinguishes it from siblings like chain or map by emphasizing evaluator-based refinement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use the tool (e.g., for iterative refinement with an evaluator) and describes evaluator forms and halting conditions. However, it does not explicitly state when not to use it or provide alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It states the return fields but does not explicitly mention read-only nature, pagination, or other behavioral traits. Inference is possible but not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff. First sentence clearly states purpose, second adds return details. Efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a parameterless list tool with an output schema, the description adequately explains the purpose and return. Could mention pagination or ordering but is generally complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. Description adds value by specifying the return fields (name, description, model, preview), which goes beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description explicitly states 'List all registered LLM-governed governors' with a clear verb and resource. It distinguishes from sibling 'list_sandbox_specs' by specifying 'governors' vs 'sandbox'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance. While the purpose is clear, the description does not contrast with alternatives or provide context for when to choose this over sibling tools like 'save_governor_spec'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears the full burden. It discloses scanning a specific directory, returning sorted summaries, and annotating live threads. It does not mention side effects or permissions, but for a read-only list tool, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences covering purpose, source, and behavior. Front-loaded with main action. Could be slightly more concise, but no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and presence of an output schema (not shown but noted), the description covers all essential aspects: what it lists, how it retrieves data, sorting, and additional annotation. No gaps detected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so per guidelines baseline is 4. The description doesn't need to add parameter info, and it doesn't repeat anything from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists pipeline runs with status, specifies file source and sorting order, and distinguishes from siblings like pipeline_status by focusing on recent runs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but provides no guidance on when to use it versus alternatives like pipeline_status or pipeline_kill. Usage context is implied but not explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so description carries full burden. It only states the directory location, omitting behaviors like error handling, sorting, or symlink following. Minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that is direct and front-loaded. Every word contributes meaning without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an existing output schema, the description is nearly complete. It could mention edge cases like missing directory, but overall adequate for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. The description adds no parameter details, but with zero parameters the baseline expectation is met.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'list' and identifies the resource as 'saved sandbox specs' with an explicit file path. It clearly distinguishes from sibling tools like 'list_governor_specs' and 'save_sandbox_spec'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., other list tools). No context on prerequisites or exclusions is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description only states the action without disclosing behavioral traits like being read-only, permissions needed, or side effects. The simplicity of listing might imply low risk, but transparency is minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no wasted words. It is front-loaded and immediately communicates the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list operation with no parameters and an existing output schema, the description is complete. It sufficiently explains the tool's action and source context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema coverage is 100%. The description adds value by specifying what is listed (registered types) and the source directory, providing context beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'List all registered types from ~/.claude/types/.' clearly states the action (list) and the resource (registered types from a specific path). It distinguishes itself from sibling tools that perform other operations like get_type_definition or inspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as get_type_definition. The description lacks context about prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It discloses key behaviors: parallel execution, defaults (model, network, tools, timeout, concurrency), and that network=true is needed for API calls. Lacks warnings about cost or resource implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description begins with a concise one-sentence purpose, followed by a well-structured argument list. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 13 parameters and an output schema, the description covers all necessary aspects: parallel execution, defaults, allowed tools, and optional settings. The output schema exists, so return values need not be explained. The tool's complexity is fully addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description's 'Args' section explains every parameter with types, defaults, and context (e.g., 'inputs: JSON array of input strings', 'network: default: true — needed for API calls'). This adds substantial meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Apply a prompt template to each input in parallel' which is a specific verb+resource, and the placeholder '{input}' clarifies usage. This differentiates from siblings like chain and map_reduce.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies parallel processing but does not explicitly contrast with alternatives like chain (sequential) or map_reduce (with reduction). No when-not-to-use guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, but description covers parallel execution, defaults for various parameters, and output schema. Omits edge cases like agent failures or cancellation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Opening sentences are concise and front-loaded. Parameter list is clear but long; could be more structured (e.g., required first).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers workflow, all parameters, defaults, and output schema. Lacks examples or error handling behavior, but sufficient for a complex tool with no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 15 parameters are described with one-line explanations adding meaning beyond names. Some descriptions are vague (e.g., effort) but overall good given 0% schema description coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool combines map and reduce in one call, explaining the fan-out and synthesis process. It distinguishes from siblings like map or reduce alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when to use (fan-out then synthesize) but lacks explicit when-not-to-use or direct comparison to separate map+reduce calls.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must disclose behavior. It covers the core parallel execution and default concurrency, but lacks details on failure handling, timeouts, resource limits, or result aggregation, which are important for a parallel execution tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very concise: a two-sentence overview followed by parameter descriptions. It is front-loaded with the main purpose and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (parallel execution) and that an output schema exists, the description should explain what the tool returns. It omits return value details, error behavior, and concurrency limits beyond the default, leaving gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds rich semantics: explains that 'tasks' is a JSON array supporting all sandbox fields and lists examples, and clarifies 'max_concurrency' default. This greatly exceeds the minimal schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs multiple Claude agents in parallel with independent configs. It distinguishes from siblings like 'chain' or 'map' through the parallel execution aspect, but does not explicitly contrast with similar tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for parallel tasks with custom configs but does not provide explicit guidance on when to use this tool versus alternatives like 'map' or 'race'. No when-not-to-use or preconditions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description fully covers behavior: asynchronous daemon thread, control flow fields (on_fail, condition, max_retries), resume semantics, and termination on unhandled failure. Comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections, bullet points for pipeline format, and front-loaded summary. Slightly lengthy but justified by complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given complexity, no annotations, and presence of output schema, the description is thorough: covers input, async behavior, control flow, error handling, resume, and references to other tools. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description richly explains both parameters: 'definition' can be name or inline JSON with detailed format; 'resume' format and behavior for resuming from run_id or step_id. Adds significant value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool launches a pipeline asynchronously and returns immediately. Distinguishes from sibling tools like pipeline_status and pipeline_kill by referencing them for monitoring/stopping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes when to use (async launch), references complementary tools, and explains control flow behavior. Lacks explicit when-not-to-use or comparison with synchronous alternatives like 'run'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description should disclose behavioral traits. It explains the listing behavior (shared/ vs step outputs, file sizes) but does not explicitly state it is read-only, safe, or mention any side effects. The behavioral info is adequate 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a single-sentence intro, followed by two clear paragraphs for the two usage modes. Every sentence adds value, and the structure is front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (two modes, output schema exists), the description covers all necessary aspects: parameters, usage modes, and hints for next steps. It does not need to detail the output schema since it is provided separately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description fully explains both parameters: run_id (required) and step_id (optional, with effects). It details the difference in behavior between providing and omitting step_id, adding significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists artifacts from a pipeline run, with two distinct modes (with/without step_id). It distinguishes from sibling tools like pipeline_status and unwrap/Read, making its purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use each mode and suggests using unwrap(ref)/Read() to view contents. However, it does not explicitly state when not to use this tool or mention any prerequisites, though context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses important behavioral traits: sets a stop event for clean loop exit and kills all Docker containers. With no annotations, this bears the full burden of transparency and does so adequately, though it lacks detail on side effects like irreversible data loss.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise and front-loaded with the main purpose. The Args section is structured but embedded in the description, making it slightly less clean. However, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple action (kill) and availability of an output schema (not shown), the description covers the essential behavior and parameter. It does not need to explain return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (run_id) with 0% schema coverage. The description adds meaning by stating 'The pipeline run ID to kill,' clarifying the purpose beyond the schema's type and title.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Kill') and the resource ('a running pipeline and all its Docker containers'). This is specific and distinguishes it from sibling tools like pipeline_status or pipeline_artifacts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The description does not mention when not to use it or provide context for decision-making among related pipeline tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden and clearly explains it reads a file (non-destructive), specifies the file path, and notes when the file is updated. This provides sufficient behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three short sentences, front-loading the purpose, and provides necessary details without unnecessary fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 param, output schema present), the description adequately covers purpose, behavior, and parameter meaning. Minor omission: no mention of possible errors, but not critical for a status check.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description explains the run_id parameter as 'The pipeline run ID returned by the pipeline() tool.', adding essential context beyond the schema's type-only definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the current status of a running or completed pipeline, using a specific verb ('Return') and resource ('status'). It distinguishes itself from sibling tools like pipeline_kill and pipeline_artifacts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates the tool is used after starting a pipeline via the pipeline() tool, and mentions the status file is written after each step, implying polling usage. It does not explicitly state when not to use it, but context from sibling tools makes the use case clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Despite no annotations, the description discloses key behaviors: tasks run simultaneously, first success returns its ref, remaining tasks are abandoned and containers killed. This provides essential behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with a clear summary line and bullet-list args. Every sentence adds value, though could be slightly more concise; overall efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-param tool with no enums, the description covers the race pattern, parallel execution, and abandonment. Output schema exists but is not shown; 'ref' is mentioned but could be clarified, but given sibling context it is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description adds meaning by referencing the task format from 'par' and explaining max_concurrency as controlling simultaneous agents. This compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs multiple approaches in parallel and returns the first to succeed, with specific verbs and resource. It distinguishes from siblings like 'par' by highlighting the race condition and abandonment of remaining tasks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends use for speculative execution or when multiple strategies might work. Implies not to use when all results are needed, but does not explicitly mention alternatives like 'par' for collecting all results, though the behavior difference is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses auto-extraction of .text fields and input handling, but does not mention that it calls a language model or potential network usage (though parameter descriptions cover defaults). Without annotations, more explicit behavioral cues would help.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise intro followed by a clear parameter list. No redundant sentences; efficiently front-loads purpose. Appropriate length for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all parameters and core behavior. With an output schema provided, return values are handled. Could explicitly note that output is a single synthesized string and that model usage may incur costs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but the description provides thorough explanations for all 9 parameters, including format clarifications (e.g., results as JSON array, sandbox spec), defaults, and allowed values, fully compensating for schema gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly describes the tool as synthesizing multiple results into one, specifying input types (plain strings or AgentResult objects) and noting it works with output from par/map, distinguishing it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage after par/map, but does not explicitly contrast with alternatives like map_reduce or state when not to use it. Provides clear context but no exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behavioral traits: retries on failure, prior error as context, type validation retry logic. Lacks details on final failure behavior, side effects, or idempotency. With no annotations, description is decent but not fully comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose stated upfront, followed by a bullet-like Args list. No redundant sentences, but could be slightly more concise by integrating defaults inline.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers main functionality but omits behavior after all retries exhausted, error handling, and does not reference output schema. For a 7-param tool with output schema, more completeness is expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but description provides brief explanations for each parameter, e.g., 'The task prompt' for prompt. Adds some meaning but lacks detail on constraints or formats.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool runs a single agent with automatic retries on failure, and explains the type validation retry condition. Distinguishes from siblings like 'run' (no retries) and 'chain' (multiple agents).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for usage: when retries are needed or type validation is desired. However, does not explicitly state when not to use or compare to alternatives like 'run' or 'beam'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It details resource acquisition, GPU access, and Docker limits, but does not explicitly state whether the operation is destructive or cleans up containers. It mentions returning 'text output and metadata' but not error handling or side effects like filesystem modifications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose, spanning multiple paragraphs with per-parameter bullet points. While organized, it could be more concise by front-loading key behavioral traits and reducing parameter explanations that could be derived from defaults. It earns space but loses efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (21 parameters, Docker orchestration), the description covers purpose, parameters, and resource management comprehensively. It lacks details on return format beyond 'text output and metadata' and does not address error or cancellation handling, but remains largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema coverage, the description fully compensates by explaining each of the 21 parameters with default values, types, and examples (e.g., mcps: 'JSON array of MCP server names to attach: ["database-mcp", "whatsapp"]'). This adds significant meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Run a single Claude agent in a Docker container.' indicating a specific verb and resource. The word 'single' hints at distinction from sibling tools like 'chain' or 'pipeline' that handle multi-step workflows, though it does not explicitly contrast them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not specify scenarios where 'run' is preferable (e.g., one-off tasks) or when to avoid it (e.g., multi-step orchestration). Sibling tools like 'chain', 'pipeline', or 'map' are not mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 details the beam_width behavior (parallel sampling, confidence-weighted majority, alternatives field) and mentions context dict accumulation. It does not specify overwrite behavior or error handling, but the core behavioral traits are well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-line purpose, followed by details on governor decisions, then a clear Args section for parameters. Every sentence adds value, and the most critical information is front-loaded. No unnecessary words or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the tool's complexity (5 parameters, beam_width behavior), the description omits the return value of the save operation and does not clarify whether re-registering an existing name overwrites or errors. With an output schema present (but not shown), the agent might infer the return type, but explicit mention would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description fully compensates by explaining each parameter in the Args section: name (unique reference), spec (natural language), description (one-line summary), model (Claude variant with default), beam_width (self-consistency with detailed behavior). This adds rich semantic meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Register an LLM-governed governor for use in pipeline control flow.' It explains what a governor does, lists possible continuations, and shows how to reference it in pipeline steps. This distinguishes it from sibling tools like list_governor_specs, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (defining a governor for pipeline steps) and explains the parameters and behavior. It does not explicitly state when not to use it or compare with alternatives, but the context is sufficient for an AI agent to understand usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the full burden. It discloses the save location and lists spec fields, but does not mention overwrite behavior, validation, permissions, or side effects. The behavioral disclosure is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a one-sentence purpose followed by a clear bullet-point list of arguments. Every sentence adds value, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with an output schema (assumed to cover return values), the description covers the action and parameters well. It lacks details on file overwriting or error conditions, but the spec field listing is thorough. Overall, it provides sufficient context for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It fully explains both parameters: 'name' with an example, and 'spec' with a list of all expected fields. This adds essential meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Save' and the resource 'sandbox spec', specifying the exact file location. It distinguishes from siblings like 'save_governor_spec' (different spec type) and 'list_sandbox_specs' (different action).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for saving reusable sandbox configurations but provides no explicit guidance on when to use versus alternatives, nor when not to use it. Siblings include many unrelated tools, but no when-to-use or when-not-to-use context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 that refs are resolved server-side, each ref gets a 'search' stamp with score and 'beam_rank', and out-of-top-k refs are marked 'pruned=True'. It also describes the return structure including run_id, winners, and ranked trace. All behavioral traits are clearly explained.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: a one-sentence purpose, then context and infrastructure points, evaluator forms, args, and returns. Every sentence adds value, and there is no wasted text. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description does not need to elaborate on return values, but it still summarizes the return JSON. It covers purpose, usage contrast, behavioral details, parameter semantics, and returns. For a tool with this complexity and many siblings, it is complete and leaves no gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains each parameter in detail: 'refs' can be an array of strings or objects, 'evaluator' supports three forms, 'top_k' controls pruning (0 means rank-only), and 'max_concurrency' has a default of 5. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool scores and ranks a list of existing refs against an evaluator. It distinguishes itself from sibling 'beam' by explaining that 'beam' fans out proposers for the same prompt, while 'score_list' handles different outputs. This provides specific verb+resource and differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool: for pipelines where N candidates already exist as refs, and contrasts it with 'beam' as the wrong shape. It explains evaluator forms, top_k behavior, and server-side ref resolution to overcome parameter size limits. This provides clear context and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description covers key behaviors: writes text to a .md file, returns the path, and explains why (to avoid bloating MCP protocol). It does not mention error handling or permissions, but the main actions are transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a one-sentence summary in the first line, followed by context and parameter details. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, output schema exists), the description is complete. It explains the purpose, usage, behavior, and parameter format. The existence of an output schema means return values don't need elaboration.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, yet the description provides detailed semantics for the single parameter 'ref': 'A ref string like "run_id/agent_id", or a JSON object with a "ref" field.' This fully compensates for the schema's lack of description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Unwrap an agent result ref — writes the full text to a file and returns the path.' It distinguishes from sibling tools like 'wrap' and 'run' by explaining that combinators return refs and unwrap extracts the text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use this tool: after combinators that return refs. It says 'Use unwrap to extract the text when you need it,' implying alternatives like not unwrapping if text isn't needed. It could be more explicit about when not to use it, but the guidance is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the tool runs an agent, returns per-criterion results, and mentions retry. However, it lacks details on side effects, auth requirements, rate limits, or resource usage, which is a gap for a validation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is moderately sized with a clear paragraph and a bulleted Args list. Every part adds value, though it could be slightly more concise by trimming redundant phrases like '— e.g.' examples.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (though not shown), the description need not repeat return values. It covers the essential context: when to use, what it does, and parameter semantics. It could mention error handling or edge cases for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% coverage, but the description compensates with a detailed Args section explaining each parameter: artifact (examples like text or file path), declared_type (type name or natural language), sandbox, model (with default), timeout. This adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: validate an artifact against a declared type, running a type-checker agent and returning VALID/PARTIAL/INVALID results. It includes a specific use case (after a pipeline step) and distinguishes from siblings implicitly by focusing on validation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this after a pipeline step to verify the output matches expectations' and advises what to do if validation fails. It does not provide direct comparison with sibling tools, but the 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full transparency burden. It discloses that the wrapped file gets a ref and can be passed to combinators, but omits details like side effects, required permissions, or whether the original file is modified.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise—two sentences plus an Args line. The first sentence clearly states the purpose, and the second adds context. Every sentence is essential with no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter) and the presence of an output schema (though not visible), the description covers the core behavior. It could mention what the ref looks like or that the original remains unchanged, but it is sufficient for most agents.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'path' has no schema description (0% coverage). The description adds meaning by specifying it must be an absolute path to a file or directory, fully compensating for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action (wrap a file/directory into the swarm ref system) and the resource (external objects). It implicitly distinguishes from siblings like 'unwrap' and 'wrap_project', but could be more precise about the monadic context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The statement 'This is how you bring external objects INTO the monadic context' provides clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are present, the description carries the full burden. It explicitly describes the side effect of adding subdirectories to search paths. It could mention potential overwrite behavior or authentication needs but is otherwise transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the main purpose. The args section adds clarity without redundancy. It could integrate the args inline but remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter and presence of an output schema, the description covers the key aspects: what it does, what directories it looks for, and the outcome. It could mention validation of directory structure or prerequisites for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description includes an 'Args' section that fully documents the 'project_dir' parameter, specifying it must be an absolute path to a project root. This adds substantial meaning beyond the input schema which only provides a title and type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool registers a project directory's pipelines, sandboxes, and types with the swarm, specifying the action, resource, and effect. It distinguishes itself from siblings like 'wrap' by focusing on project directories.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that after wrapping, resources become discoverable by all swarm tools, providing clear context for when to use it. However, it does not explicitly mention when not to use it or provide alternatives to siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.