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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that assertions must be grounded by evidence, but does not disclose side effects (e.g., how the assertion is added to the theory), whether existing assertions are overwritten, or any permission/validation requirements. This is a significant gap for a mutation 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 three sentences long, front-loaded with the core purpose, and every sentence adds substantive value (what it does, what assertions are, the grounding requirement). There is no redundancy or filler.

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

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

Given the tool's complexity (6 parameters, no annotations, no output schema), the description is incomplete. It does not explain the return value, how to obtain evidenceId, what happens if the assertion conflicts with existing theory, or how confidence is used. The description covers the 'what' but not the 'how' or 'when' details.

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%, yet the description only clarifies that assertions are 'typed beliefs' (hinting at assertionType) and must be grounded by evidence (relevant to evidenceId). It does not explain content, regionId, confidence, or the exact format of evidenceId. With six parameters and no schema descriptions, the description fails to adequately compensate.

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 specific action ('Add an assertion'), the resource ('synthesis theory'), and the key requirement of evidence grounding. It distinguishes itself from sibling tools like list_assertions_tool and contract_assertion_tool by focusing on adding a grounded assertion.

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 does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The evidence grounding requirement implies a precondition, but there is no clear guidance on selecting this tool over related tools like store_evidence_tool or revise_theory_tool.

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 responsibility for disclosing behavior. It accurately conveys that the tool classifies failure modes and suggests assertion contractions, which implies non-mutating analysis. However, it does not explicitly state whether the tool is read-only, what side effects (if any) occur, or any prerequisites such as an existing failed synthesis run. This leaves some ambiguity.

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

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

The description is a single, well-structured sentence that front-loads the primary action and then adds supporting detail. Every word contributes meaning, with no redundant or filler content.

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 tool has five parameters, no output schema, and no annotations, so the description needs to explain inputs, outputs, and required context. It does not describe the return format or how the suggested assertions are presented, nor does it clarify what 'contract an assertion' means in this workflow. The description is too sparse for an agent to confidently invoke the tool and interpret results.

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 by explaining parameter usage. It does not mention any of the five parameters (projectId, regionId, errorMessage, testPassRate, mutationScore) or how they relate to the analysis. The connection to failure mode is implicit but not sufficient; an agent would not know which parameters to provide.

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

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

The description uses a specific verb ('Analyze') and identifies the resource ('synthesis attempt failed'), clearly distinguishing it from siblings like synthesis_status_tool or run_unit_tests_tool. It also states the two key outputs (failure mode classification and suggested assertions to contract), making the tool's 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 implies usage after a synthesis attempt fails but does not explicitly state when to prefer this tool over alternatives or provide exclusions. It doesn't mention alternatives like synthesis_status_tool for checking run status or synthesize_patch_tool for generating fixes, so guidance is only 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?

With no annotations, the description must disclose behavioral traits itself. It explains the return value and provides interpretation, but it does not explicitly state whether the tool is read-only, what happens if the assertion is not found, or any other side effects. This is adequate for a simple measurement tool but leaves gaps.

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

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

The description is two sentences, front-loaded with the purpose and output scale. It is concise, with no wasted words, and the structure is clear.

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 measurement tool with two parameters, the description is mostly complete: it explains the output and its interpretation. However, it does not cover error conditions, parameter details, or potential side effects, so it is not fully complete.

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

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

The schema has 0% description coverage for parameters, and the description does not explicitly explain projectId or assertionId. It only mentions 'an assertion,' which provides minimal context. The names are self-explanatory to some extent, but the description fails to compensate for the lack of schema descriptions.

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

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

The description clearly states the tool measures the stability of an assertion and specifies the output range (0.0 to 1.0). However, it does not explicitly distinguish itself from similar tools like get_entrenchment_tool, so it lacks the sibling differentiation required for a 5.

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 by noting that unstable assertions may need stronger evidence or reformulation, but it does not explicitly state when to use this tool versus alternatives such as get_entrenchment_tool or why_believe_tool. Usage is implied but not clearly bounded.

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 of behavioral disclosure. It goes beyond a simple 'cancel' by explaining that it sets a cancellation flag that the CEGIS engine checks between iterations, informing the agent that cancellation is not necessarily immediate. It does not detail return values or failure handling, but the key side-effect is disclosed.

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

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

The description is two sentences, front-loaded with the primary purpose, and each sentence adds essential information. There is no fluff or 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?

For a tool with one parameter and no output schema, the description sufficiently covers purpose and the asynchronous cancellation behavior. Although it does not mention return values or error conditions, the low complexity and available sibling tools (e.g., synthesis_status_tool) provide enough context for an agent to invoke it correctly.

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%, yet the description does not explain the synthesisId parameter or where to obtain it. The parameter name is self-explanatory to some degree, but the description adds no semantic value about how the ID relates to the cancellation process.

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

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

The description uses a specific verb ('Cancel') and resource ('running synthesis'), clearly distinguishing this from sibling tools like synthesize_patch_tool or synthesis_status_tool. The phrase 'running synthesis' precisely scopes the 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?

The description implies when to use the tool: when a synthesis is currently running and needs to be stopped. It does not explicitly name alternatives or provide exclusions, but the 'running' precondition and the cancellation mechanism give clear 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?

No annotations are provided, so the description carries the full burden. It explains the semantics of 'contains' (file vs function regions), which is valuable. However, it does not disclose the return format (e.g., boolean or relationship type), possible side effects (even though 'check' implies read-only), or edge cases like self-containment or parameter order. The behavioral disclosure is partial.

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

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

The description is three sentences, front-loaded with the core purpose, followed by a use case and a clarifying semantic note. Every sentence adds value, with no filler or redundancy. It is appropriately sized for a simple tool.

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 low complexity (two string parameters, no output schema, no annotations), the description covers the main aspects: what it does, when to use it, and the meaning of the relationship. However, it omits the return value specification and any potential prerequisites or failure modes, which are especially important because no output schema or annotations exist. For a simple check tool, this is nearing completeness but has a notable gap.

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

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

Schema coverage is 0% and the description does not explicitly explain the parameters 'regionA' and 'regionB'. While the tool's purpose implies they are the two regions to compare, there is no guidance on the expected string format (e.g., file path, region ID) or how to reference file vs. function regions. The description's note about file/function regions adds some semantic context but does not compensate for the lack of parameter details.

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 function with a specific verb and resource: 'Check if one region contains or overlaps another.' It also clarifies the meaning of 'contains' for file and function regions, which uniquely positions it among region-related tools. No sibling tool offers this relationship-checking capability.

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 a clear use case: 'Useful for aggregating metrics across related regions.' This gives the agent context on when to employ the tool. However, it does not explicitly mention exclusions or alternative tools, though siblings like get_region_metrics_tool or parse_region_tool might be relevant in other scenarios.

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 burden. It explains the algorithm and return values well, but does not explicitly state whether the operation is safe/read-only or if it has side effects, permissions, or performance 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?

Two dense sentences with no filler. The first sentence states the purpose immediately and the second gives method and output, making it very 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 lack of output schema, annotations, and parameter descriptions, this tool description is incomplete. It fails to explain parameter semantics, usage context, or prerequisites, leaving significant gaps for a moderately complex 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%, and the description does not explain any of the three parameters (workingDirectory, max_depth, min_partition_size). The recursive bipartition mention implies some relationship to max_depth, but it is not explicit, leaving the agent to infer meaning.

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

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

The description uses a specific verb ('Compute') and defines exact resource ('Fiedler spectral partitioning of a project's call graph'), clearly distinguishing it from sibling tools like find_function_partition by naming a specific spectral method.

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 given on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an extracted call graph) 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does a good job by specifying exactly what gets removed under each strategy (target and less-entrenched dependents, edges only, all descendants), which is crucial for a destructive operation. However, it omits details about reversibility, return behavior, or broader project side effects, preventing a top 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 sentences with no wasted words. The first sentence front-loads the primary action and the second efficiently lists all three strategies with parenthetical clarifications. The structure makes the tool easy to scan and understand.

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 is complete for the core operation and strategy selection, but since there is no output schema and no annotations, it should also clarify what the tool returns after contraction (e.g., updated theory, success status) and any potential error conditions. Without this, an agent may be uncertain about postconditions for this destructive theory operation.

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

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

The input schema provides no descriptions for parameters, and the description adds substantial meaning to the 'strategy' parameter by explaining all three possible values and their effects. 'nodeId' and 'projectId' are not explicitly described, but their roles are strongly inferable from the tool's purpose and names. This compensates for the zero schema coverage well, but not perfectly.

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

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

The description uses a specific verb-resource pair ('Contract (remove) an assertion from the theory') and immediately distinguishes the tool from siblings like add_assertion_tool and revise_theory_tool by naming AGM contraction and listing three concrete strategies. The purpose is unmistakable and robustly differentiates from other 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 clearly implies when to use this tool: when removing an assertion via AGM contraction, and it even provides guidance on selecting among strategies (entrenchment, minimal, full_cascade). However, it does not explicitly name alternatives or conditions for when not to use this tool, so it falls short of an explicit when/when-not statement.

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 of behavioral disclosure, but it only mentions what the tool does without detailing side effects, prerequisites, or return values. There is no indication of whether creation is idempotent, what happens on invalid input, or whether it modifies persistent state. This is a significant gap for a creation 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, with two sentences that front-load the core purpose and then provide level semantics. Every sentence contributes meaningful information, and there is no redundant filler.

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 tool has 6 parameters, 1 required, no output schema, and no annotations, yet the description only covers the 'level' parameter semantics. It leaves out crucial context such as how to combine parameters for each level, any error conditions, and what the function returns. For a tool with this complexity, the description is incomplete.

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 meaning of each 'level' value, which partially clarifies the relevance of funcName, className, and lineStart/lineEnd, but it does not explicitly map levels to parameter names or state whether lineStart/lineEnd are both required for 'lines'. The required filePath parameter is not mentioned at all, leaving some parameters underspecified.

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 function: creating a region identifier for a code location. It specifies valid level values, which distinguishes it from sibling tools like parse_region_tool or get_region_metrics_tool. The verb 'create' plus the resource 'region identifier' is specific and 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 gives implicit guidance on when to use this tool (whenever a region identifier is needed), but it does not explicitly distinguish it from alternatives or state when not to use it. The level-specific instructions are more about parameter selection than tool selection, so usage context is only implied rather than fully elaborated.

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 of behavioral disclosure. It does not state whether the tool is read-only, what it does with the workingDirectory, or any error conditions. While it mentions return values, it fails to disclose side effects or operational details, which is a significant gap for a tool with zero annotation coverage.

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

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

The description is two concise sentences with no wasted words. It front-loads the action ('Detect') and clearly states the outputs, making it highly efficient 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?

For a tool with one parameter and no output schema, the description covers the main purpose and return values, but it lacks parameter semantics and explicit usage context relative to siblings. It is adequate for a basic understanding but not fully complete, especially given the missing annotations and parameter clarification.

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

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

The input schema has one required parameter, workingDirectory, but the description never mentions it or provides any guidance on its format, semantics, or expected values. With 0% schema description coverage, the description must compensate by explaining the parameter, which it does not. This leaves the agent without critical input information.

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 'Detect' and names the resource ('available mutation testing frameworks and project language'), clearly distinguishing it from sibling tools like run_mutation_tests_tool. It also explicitly states what it returns (frameworks with confidence scores and a recommendation), making the tool's purpose unmistakable.

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

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

The description implies this tool should be used to identify frameworks before running mutation tests, but it does not explicitly state when to use it vs alternatives or provide exclusions. There is no mention of prerequisites or the relationship to sibling tools like run_mutation_tests_tool, leaving usage guidance 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.

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

No annotations are provided, so the description carries the burden. It indicates the operation is analytical ('Extract and analyze') and discloses output statistics, but does not state whether it modifies anything, requires a build step, or has side effects. The description is not misleading but lacks depth about potential limitations or read-only guarantees.

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, front-loaded with the main purpose, followed by a compact list of return statistics. No wasted words or redundant repetition of the tool name.

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 two-parameter tool with no output schema, the description adequately covers the return contract. However, the unexplained 'backend' parameter is a notable gap given the absence of schema descriptions, preventing full completeness.

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

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

Schema coverage is 0%, and the description does not explain either parameter. It mentions 'of a Python project' which hints at workingDirectory but never maps it to the parameter. The 'backend' parameter is completely undocumented, leaving the agent without guidance on valid values or purpose.

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

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

The description uses a specific verb phrase 'Extract and analyze' with a clear resource ('call graph of a Python project') and lists concrete return values (node count, edge count, SCC count, etc.). This distinguishes it from sibling tools focused on testing, synthesis, and graph queries.

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 clearly implies when to use this tool (when analyzing a Python project's call graph structure) but does not explicitly mention alternatives or exclusions. The context is clear enough for an agent to select it for call-graph analysis, though it could benefit from stating that it is for static analysis and not for dynamic tracing.

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 the full burden of behavioral disclosure. It clearly discloses the output structure (partition ID, sibling functions, entry/exit points) and implies a read-only query operation. However, it does not mention error behavior or prerequisites (e.g., function must exist), which prevents a higher 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?

The description is two concise sentences, front-loaded with the primary purpose and then detailing the return values. Every word contributes meaning with no redundancy or filler.

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 query tool with 2 parameters and no output schema, the description covers the return values but leaves the workingDirectory parameter unexplained. It also lacks context about when to use this tool or what happens if the function is not found. It is adequate but has clear 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?

The schema has no property descriptions (0% coverage), so the description must compensate. It implicitly clarifies function_name by mentioning 'a function,' but provides no explanation for workingDirectory. The parameter semantics are therefore only partially addressed.

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 specific purpose: finding which partition a function belongs to in the Fiedler partition tree. It also lists the exact return values (partition ID, sibling functions, entry/exit points), making it distinct from sibling tools like compute_partitioning.

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 such as compute_partitioning or check_region_relationship. There are no prerequisites, exclusions, or explicit alternative references, leaving the agent to infer usage from the purpose alone.

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 discloses that entrenchment ranges 0.0-1.0 and that higher values mean harder to remove via contraction, which provides meaningful context about the tool's interpretation. However, it omits details like return format, error behavior, and prerequisites, so it is not fully 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 two sentences, front-loaded with the main purpose, and contains no filler. It efficiently conveys both the function and the meaning of the score.

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 get operation, the description explains the score's meaning but omits parameter semantics, return format, and differentiation from related tools. Given the lack of annotations and output schema, it is minimally adequate but with clear 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% and the description does not explain the parameters. The mention of 'assertion' hints that nodeId identifies an assertion, but projectId and nodeId are otherwise left undefined in both schema and description.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Get the entrenchment score for an assertion.' It also explains the concept of entrenchment, but does not explicitly distinguish from similar siblings like belief_stability_tool.

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 such as belief_stability_tool or why_believe_tool. It only states what it does without any usage context, conditions, 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?

With no annotations, the description carries the full burden for behavioral disclosure. It reveals the algorithm ('alternates between SCC condensation and Fiedler spectral partitioning') and the output type (a tree), but it does not state side effects (e.g., whether it is read-only), prerequisites (e.g., whether a call graph must already be built), or performance implications. This is a moderate level of transparency.

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

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

The description is two sentences long, front-loaded with the main verb and resource, and includes relevant algorithmic detail without any fluff or redundancy. Every sentence earns its place.

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

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

Given the tool's complexity (alternating algorithms) and the absence of an output schema, the description is incomplete. It does not explain what the tree represents, how the single parameter is used, or how this tool relates to sibling graph tools (e.g., whether extract_call_graph must be called first). This leaves significant gaps for an agent attempting to invoke the tool correctly.

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% description coverage, and the tool description does not mention the required 'workingDirectory' parameter or explain what it represents. The agent is given no guidance on what value to pass (e.g., a path to a project root). The description fails to compensate for the schema's lack of parameter documentation.

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: 'Get the hierarchical decomposition of a project's call graph' with a specific verb and resource. It also mentions the output (a tree representing modular structure) and the two techniques used, which distinguishes it from sibling tools like extract_call_graph or compute_partitioning.

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

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

The description implies when to use the tool (when you need a hierarchical tree of the call graph) but does not explicitly state when to prefer it over alternatives. It does not mention exclusions or alternatives, such as compute_partitioning for a flat partition or extract_call_graph for a raw graph. The guidance is implicit rather than 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' and 'Shows' clearly indicate a read-only operation, and the description lists the types of events included in the history, giving the agent a clear idea of what to expect. It does not explicitly state that no modifications occur, but the language is sufficient.

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

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

The description is two sentences long and immediately states the main action ('Get the provenance DAG summary'), followed by a concise explanation of what it shows. Every word contributes value, and there is no redundant information.

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 tool has one parameter, no output schema, and no annotations, so the description is the only guide. It clearly explains the purpose and content of the returned history, which is sufficient for an agent to decide to invoke it. However, it does not describe the structure of the DAG summary or the exact return format, which could be a minor gap given the absence of an output schema.

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

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

The schema coverage is 0%, so the description must compensate. The description mentions 'for a project's synthesis theory,' providing context that projectId refers to the project of interest. However, it does not explicitly describe the parameter, its format, or any constraints beyond the schema's type and required status. For a single self-explanatory parameter, this is adequate but not thorough.

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 retrieves a provenance DAG summary for a project's synthesis theory and enumerates the specific history it shows (expansions, contractions, revisions, evidence storage events). This makes it distinct from sibling tools like get_theory_snapshot_tool or why_believe_tool, which focus on current state or reasoning.

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

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

The description implies when to use the tool: when you need the history of belief revision operations for a project's synthesis theory. However, it does not explicitly contrast with alternatives or state when not to use it. Sibling tools like get_theory_snapshot_tool likely serve a different purpose, but this is not stated.

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 of behavioral disclosure. It indicates a computation but does not state whether any side effects occur, what prerequisites exist (e.g., commitSha must reference a valid commit), or what the return value contains. This is insufficient for safe and correct invocation.

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

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

The description is a single, front-loaded sentence that conveys the primary action without unnecessary words. It earns a 4 rather than 5 because it omits important details, but it is appropriately concise and structured.

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

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

With no output schema and no annotations, the description must explain the tool's context fully, but it does not. It fails to describe what 'PID-like metrics' means, what the return value contains, or how the parameters affect the computation. The description is a minimal viable statement but leaves significant 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 description coverage is 0%, and the description only implies 'project' and 'region' without explaining them. The required commitSha parameter is not mentioned at all, and the relationship between parameters is unclear. The description fails to compensate for the schema's lack of detail, leaving the agent to guess parameter meanings.

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

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

The description states 'Compute PID-like metrics and mutation score for a specific region within a project,' using a specific verb and naming the resource and scope. It distinguishes from siblings like run_mutation_tests_tool by focusing on computing metrics rather than executing tests. However, 'PID-like metrics' is jargon that is not defined, which slightly blurs the purpose.

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 offers no guidance on when to use this tool versus alternatives. It does not mention that it is a read-only computation, nor does it exclude cases where running mutation tests would be more appropriate. This lack of contextual guidance leaves the agent to infer usage from the tool name alone.

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 of behavioral disclosure. It only says 'Return', implying a read operation, but does not disclose ordering, pagination, limit semantics, failure behavior, or response format. The minimal phrase 'recent' adds some context but is insufficient for a tool with zero annotation support.

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, well-structured sentence with no redundancy. It front-loads the verb and immediately specifies the resource and optional filter, making it easy to parse quickly.

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

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

For a simple history-retrieval tool, the description covers the core purpose and main parameters. However, with no output schema, no annotations, and no mention of 'limit' behavior or return format, it is only minimally complete. It would benefit from noting ordering or how to control the number of results.

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 clarifies that region is optional and links project/region to the primary parameters, but does not explain the 'limit' parameter at all, nor provide formats or constraints. The description partially compensates but leaves a significant 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 action ('Return') and specific resource ('recent unit, integration, and mutation runs') plus scope ('for a project and optional region'). This distinguishes it from sibling tools like run_unit_tests_tool or run_integration_tests_tool, which execute runs rather than retrieve history.

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 viewing past test runs, and the optional region parameter adds context. However, it does not explicitly state when to prefer this over sibling tools or mention any exclusions or prerequisites. Usage guidance is only contextual, not direct.

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 burden. While it tells the agent the return content, it does not explicitly state whether the operation is read-only or if it has any side effects. The verb 'Get' and 'snapshot' imply non-destructive behavior, but this is not made 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?

The description is compact, two short sentences, with no filler. It front-loads the action and then clarifies the return 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 lack of an output schema and annotations, the description provides some essential return information but omits any explanation of the projectId parameter, what a 'world bundle' entails, or when to choose this over related tools. For a one-parameter tool, it is adequate but not comprehensive.

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

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

The input schema has one parameter, projectId, but the schema description coverage is 0% and the tool description does not mention the parameter or how it affects the snapshot. The agent must infer from the parameter name that it identifies the project.

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 retrieves a snapshot of the current synthesis theory and enumerates the content (nodes, edges, evidence). This distinguishes it from sibling tools that perform other operations like revision or verification.

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 this tool should be used when a full view of the theory is needed, but it does not explicitly contrast it with alternatives like graph_query_tool or get_hierarchy, nor does it state 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?

With no annotations, the description alone must carry behavioral disclosure. It clearly states that the tool reads stored graph data without re-extraction and mentions the Kameda O(1) index for reachability, which is informative. However, it does not explicitly confirm a read-only side-effect-free profile, mention permission requirements, or describe error behavior.

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

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

The description is two sentences, front-loads the core action, and lists query types compactly. Every sentence provides value with no redundant or filler content.

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

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

Given 7 parameters, no output schema, no annotations, and overlapping sibling tools, the description is incomplete. It lacks parameter combination requirements per query type, return format, error handling, and any guidance distinguishing it from `query_reachability` or `persistent_graph_stats_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 description coverage is 0%, so the description must compensate. It explains the `queryType` values (neighbors, reachability, node) and gives context for reachability's source/target relationship, but it leaves `nodeId`, `targetNodeId`, `edgeKind`, `direction`, and the roles of `projectId`/`workingDirectory` largely undefined. Most parameters are not semantically clarified.

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

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

The description clearly identifies the tool as executing structured graph queries against a persistent store and enumerates three specific query types (neighbors, reachability, node). It is specific about the resource (graph store) and verb (query), but does not explicitly differentiate it from sibling tools like `query_reachability`, which overlaps in purpose.

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 phrase 'Uses stored graph data without re-extraction' implies when the tool is appropriate, but there is no explicit guidance on when to prefer this tool over overlapping siblings such as `query_reachability`, `extract_call_graph`, or `persistent_graph_stats_tool`. No exclusions or alternative recommendations are 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 are provided, so the description carries the full burden of behavioral disclosure. It explains the mechanism (comparing file hashes, updating only affected nodes) and the performance benefit, but it does not disclose potential side effects (e.g., whether changes are permanent), prerequisites (e.g., whether an initial extraction is required), or error behavior. This is adequate but not thorough.

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: three sentences, each adding value. The first states the purpose, the second explains the mechanism, and the third provides a key benefit. There is no redundancy or fluff, 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?

The description gives a solid overview of the tool's core behavior and advantage, but it is incomplete given the lack of annotations and output schema. It does not mention prerequisites (e.g., an existing persisted call graph), what happens if no changes are detected, or how the tool integrates with extraction tools. For a moderately complex incremental update operation, this level of detail is only minimally viable.

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 3 parameters (pattern, projectId, workingDirectory) with 0% coverage, meaning no descriptions are provided in the schema. The main description also does not explain any of these parameters, their roles, or how they relate to the tool's functionality. This is a significant gap, as the agent has no guidance on what values to provide or how they affect the incremental update.

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 function: 'Detect file changes and update the persisted call graph incrementally.' It specifies a specific verb ('update'), a specific resource ('persisted call graph'), and distinguishes itself from full re-extraction, which is a sibling tool ('extract_call_graph').

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

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

The description implies when to use the tool by contrasting it with full re-extraction ('Much faster than full re-extraction'), suggesting it is the preferred choice for updating an existing graph when file changes occur. However, it does not explicitly state when not to use it or name the alternative tool, though the sibling list includes extract_call_graph.

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 clearly states the action and filter options, but does not disclose return format, pagination, combined filter semantics, or error behavior. The read-only nature is implied by 'List' but not explicitly stated.

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

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

The description is two sentences, front-loaded with the primary verb and resource, and includes all necessary filter information without redundancy. Every word contributes 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 nature of the tool, the description covers the core behavior and filters. However, with no output schema, the agent does not know the shape of the returned list, and edge cases like missing projectId or combined filters are not addressed. The sibling context helps, but the description itself is incomplete for a fully aware invocation.

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

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

Schema coverage is 0%, so the description adds meaning beyond the schema. It explicitly lists the acceptable assertionType values ('type, behavior, invariant, contract') and mentions regionId as a filter. projectId is not described, but its name and required status make it self-explanatory.

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

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

The description uses a clear verb ('List') with a specific resource ('assertions in the synthesis theory') and optional filters. It distinguishes this tool from sibling tools like add_assertion_tool and contract_assertion_tool, which perform different operations.

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: call this when you need to list assertions. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. For a simple list operation, the context is clear but not fully 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?

With no annotations, the description carries the burden. It discloses that the tool returns a summary with outcomes, iterations, and fitness, which gives insight into the response. However, it doesn't address read-only semantics, pagination, or errors. The verb 'List' implies a read operation, but it's 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 concise sentences, front-loaded with the action and resource, followed by the return summary. No redundant wording.

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?

As a simple listing tool with no output schema and no annotations, the description covers the primary purpose and some return content, but lacks edge cases, differentiation from siblings, and details on the summary structure. Adequate for basic selection but not fully complete.

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

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

Schema coverage is 0%, and the description only loosely ties the projectId parameter to a 'project' without explaining format, source, or requirements. For a single parameter, this is minimal but not absent.

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

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

The description uses a specific verb ('List') with a clear resource ('all synthesis runs') and scope ('for a project'), and adds return details. It doesn't explicitly contrast with similar siblings like get_run_history_tool, but the resource is specific enough.

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 choose this over alternatives such as get_run_history_tool or list_verification_backends_tool. The description provides no context for when to use or when not to use.

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 discloses the primary behavior (listing backends) and adds specific content details (which predicates and constraint types are shown). This provides a clear picture of the tool's output. There is no mention of side effects or edge cases, but for a read-only list operation, the description is adequately 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, consisting of two short sentences. It is front-loaded with the core action ('List available verification backends') and then supplements with specific details. Every word provides value; there is no fluff 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?

For a zero-parameter tool with no output schema, the description is complete. It explains what the tool does and what information it returns (backend capabilities, predicates, constraint types). There is no missing context that would hinder an agent from invoking it correctly, given its simple nature.

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

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

The tool has zero parameters, so the input schema provides no parameter details. According to the rubric, a 0-parameter tool gets a baseline score of 4. The description does not need to explain parameters, and it adds no redundant information. There is no gap to compensate for.

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 function: listing available verification backends and their capabilities. It uses a specific verb ('List') and resource ('verification backends'), and the additional detail about find/avoid predicates and constraint types differentiates it from sibling tools that run tests or analyze regions.

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 its usage—to discover backend capabilities—but it does not explicitly state when to use it versus alternatives or mention any exclusions. For a simple listing tool, the context is somewhat clear, but there is no explicit guidance about prerequisites or 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.

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 reveals the output contents ('world hashes with timestamps and reasons') but does not mention pagination, ordering, potential performance impact, or any side effects. This is adequate for a simple list operation but lacks depth.

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, front-loaded sentence that states the purpose, the return value, and the primary use cases without any filler or redundant information. Every element earns its place.

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

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

For a straightforward list tool with one parameter, the description covers the core purpose, return content, and rationale. However, since there is no output schema, it could be more explicit about the exact response structure (e.g., array format, ordering) to be fully complete.

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

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

The schema provides no description for projectId (0% coverage). The description indirectly clarifies the parameter by stating the tool lists history 'for a project's synthesis theory,' implying projectId identifies which project. However, it does not explicitly explain the parameter's format or constraints, leaving the agent to infer.

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 ('List') and the resource ('historical world states for a project's synthesis theory'), and specifies what is returned ('world hashes with timestamps and reasons'). This distinguishes it from sibling tools that list runs, assertions, or backends, making its unique 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 gives explicit use cases: 'useful for understanding theory evolution and choosing rollback targets.' This provides clear context on when to employ the tool, although it does not explicitly name alternatives or state 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.

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 explains the input format and that the tool parses into components, implying a read-only operation. However, it does not disclose error behavior, validation rules, or the exact structure of the parsed output. This is a moderate level of transparency, similar to parse tools that are assumed to be pure functions.

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

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

The description is two sentences long and front-loaded with the primary action. The first sentence states the purpose, and the second provides the format and a usage hint. There is no extraneous information, making it appropriately concise.

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

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

The tool is simple (one parameter, no output schema), but the description does not fully explain the return value or error behavior. Since no output schema exists, the description should clarify what the parsed components look like (e.g., an object with keys file, class, func, lines). The mention of 'into its components' is helpful but incomplete without specifics.

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

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

The input schema only lists 'regionId' with no description, and schema description coverage is 0%. The description compensates by specifying the expected format: 'file:<path>::class:<name>::func:<name>::lines:<start>-<end>.' This provides essential meaning beyond the bare schema. It would earn a 5 if it included an example or further detailed each component's constraints.

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 function: 'Parse a region identifier string into its components.' It also provides the specific format for region identifiers, which distinguishes it from sibling tools like check_region_relationship_tool or get_region_metrics_tool. The verb 'parse' is specific and 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 includes a clear usage context: 'Useful for understanding region hierarchy.' It does not explicitly mention alternatives or when not to use this tool, but the context is sufficient for an agent to infer appropriate use cases. The lack of exclusions keeps it at a 4 rather than a 5.

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 of behavioral disclosure. It communicates that the tool retrieves statistics and details the return fields, which implies a read-only operation. However, it lacks explicit statements about side effects, error behavior, or permission requirements, which are not covered elsewhere.

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, well-structured sentence that front-loads the action and resource, then concisely enumerates the return metrics. There is no redundant information or filler; every word contributes to understanding the tool's function.

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 statistics tool with no output schema, the description adequately lists what the tool returns and states its purpose. However, it omits important context such as usage timing, prerequisites, and parameter semantics, which are not covered by schemas or annotations. This makes the description only minimally 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?

The schema provides no descriptions for the two parameters (projectId, workingDirectory), and the description does not compensate by explaining their meaning or format. Although the parameter names are somewhat self-evident, the 0% schema coverage and absence of any parameter guidance in the description leave the agent without sufficient information to construct valid inputs.

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

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

The description uses a specific verb ('Get') and resource ('persistent graph store for a project') and explicitly lists the returned statistics (node count, edge count, Kameda index status, backend type, last update timestamp). This clearly distinguishes it from sibling tools like rag_stats_tool, which targets the RAG store.

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 does not mention when to use this tool versus alternatives, nor does it state any exclusions or preconditions (e.g., that a project must exist, or that the working directory must be valid). It simply states what the tool does, leaving usage entirely implied.

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 the algorithmic approach (Kameda O(1) index with BFS fallback) and the return structure, including that the path is returned only when BFS is used. This adds useful behavioral context, though it does not mention prerequisites like needing an index or potential side effects, which is reasonable for a read-only query.

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

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

The description is two sentences, with the first front-loading the core purpose and the second providing algorithmic and output details. Every sentence earns its place 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 the tool has no output schema and no annotations, the description does a good job covering the essential behavior and return values. It does not mention prerequisites (e.g., whether a pre-built index or call graph is required), which could be important context for an agent, but the core operation is well-explained.

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 implicitly identifies source_function and target_function as the two endpoints ('between two functions') but adds no detail about their expected format. The workingDirectory parameter is entirely unaddressed in the description. This is minimal compensation for the lack of schema descriptions.

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

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

The description clearly states the tool's function with a specific verb ('Query') and resource ('reachability between two functions in a project's call graph'). It distinguishes itself from sibling tools like extract_call_graph or compute_partitioning by focusing on reachability queries, and it outlines the output (whether reachable, method used, path if via BFS).

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

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

The description implies usage when one needs to determine if one function can reach another in a call graph, but it provides no explicit exclusions, alternatives, or comparison to sibling tools like graph_query_tool. The context is clear but lacks any 'when-not' or 'use instead' 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?

No annotations are provided, so the description carries the full burden of disclosing behavioral consequences. It describes an indexing (write/mutation) operation, but does not state whether indexing overwrites existing nodes, whether it is idempotent, requires specific permissions, or how persistDirectory affects behavior. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

The description is two sentences, front-loaded with the core action, and the second sentence adds genuinely useful information about node requirements. 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?

The tool has no annotations, no output schema, and 0% schema description coverage, yet the description only covers the basic action and node structure. Missing details like return behavior, failure modes, duplicate handling, and parameter roles leave significant context gaps for an indexing 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 description coverage is 0%, so the description must compensate. It explains the structure of the 'nodes' array (ID, text, optional metadata), but does not clarify the meaning of projectId, collection, or persistDirectory. Three of four parameters remain semantically unresolved, which is inadequate for an unannotated tool.

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

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

The description uses a specific verb 'Index' with a specific resource 'code nodes into the RAG vector store for semantic search,' clearly differentiating from sibling search/stats tools. It also states node structure (ID, text, optional metadata), further clarifying the tool's purpose.

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 populating the vector store before semantic search, but it does not explicitly state when to choose this tool over alternatives like rag_search_tool, nor does it mention any preconditions or exclusions. This is implied usage rather than explicit 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the core read-only search behavior and the optional graph expansion, but does not detail output format, cost, or side effects. This is minimal but not misleading.

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

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

The description is two sentences, front-loaded with the primary action, and contains no filler. Every word earns its place, making it appropriately concise.

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

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

Given six parameters, no output schema, and no annotations, the description is insufficient. It doesn't explain return values or the meaning of key parameters, and the graph expansion behavior is only vaguely described.

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

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

Schema description coverage is 0%, and the description adds no explanation for any of the six parameters. It only mentions 'query' implicitly, while properties like topK, projectId, collection, workingDirectory, and useGraphExpansion remain unexplained.

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

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

The description clearly states the tool's function: searching the RAG vector store for code relevant to a query. It also mentions the optional call graph expansion, which distinguishes it from sibling tools like rag_stats_tool and rag_index_nodes_tool.

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 finding relevant code via vector search, but provides no explicit guidance on when to choose this over alternatives like graph_query_tool or query_reachability. It doesn't state exclusions or alternatives, leaving usage inference to the agent.

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 the full burden. It only says 'Get statistics' without disclosing whether it is read-only, what side effects exist, whether the collection parameter affects the result, or what output format to expect. Minimal behavioral information is provided.

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, direct sentence with no filler. It is appropriately structured and front-loaded, though brevity comes at the cost of missing critical detail.

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 tool with one optional parameter, no output schema, and no annotations, the description is incomplete. It doesn't explain what statistics are returned, the significance of the collection parameter, or how this differs from similar retrieval tools. The agent would need to guess at behavior.

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

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

The schema has one parameter (collection) with 0% schema_description_coverage. The description does not mention the collection parameter at all, failing to compensate for the absence of parameter explanations in the schema. The agent gets no semantic guidance beyond the parameter name and default.

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 'Get' and the resource 'statistics about the RAG vector store', which is a specific purpose. While it doesn't explicitly differentiate from siblings like persistent_graph_stats_tool, the RAG-specific scope provides reasonable clarity.

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

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

The description gives no guidance on when to use this tool versus alternatives, no exclusions, and no contextual prerequisites. It merely states what it does without any usage direction.

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 existing beliefs are first contracted if the new assertion contradicts them, and names the specific formal method (AGM revision / Levi identity). This provides meaningful insight into the operation's side effects, though it does not mention other potential effects like logging or rollback.

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

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

The description is two sentences, front-loaded with the primary action. Every word adds value, and the technical reference is compact. There is no redundancy or filler.

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 core algorithm is well explained, but the tool is complex (6 parameters, no output schema, no annotations) and the description omits parameter guidance and return behavior. It also does not explicitly contrast with sibling tools. It is a reasonable overview but leaves notable gaps for a sophisticated revision operation.

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

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

Schema description coverage is 0% and the description does not explain any of the six parameters. While it says 'incorporating a new assertion', it never connects this to the 'content', 'assertionType', 'contractionStrategy', or any other field. The agent cannot infer what values these parameters should take from the description alone.

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

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

The description uses a specific verb ('Revise') and resource ('the theory'), and explains the key mechanism (AGM revision / Levi identity). This distinguishes it from sibling tools like add_assertion_tool and contract_assertion_tool, 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 gives clear context: it is used when incorporating a new assertion into a theory, with handling for contradictions. It does not explicitly state when to prefer this over add_assertion_tool or contract_assertion_tool, but the contraction behavior implies it is for revision scenarios rather than simple add or contract operations.

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 the transparency burden. It provides important behavioral context: rollback uses content-addressable storage, no data is lost, and only the current world pointer changes. This assures the agent that the operation is non-destructive and explains the underlying mechanism. It doesn't cover error cases or permissions, but the core behavior is well disclosed.

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 only two sentences, with the main action immediately stated and no filler. The additional detail about content-addressable storage is relevant and earns its place.

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

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

For a two-parameter tool with no output schema, the description gives a solid mental model: the action, the safety properties, and the underlying mechanism. It doesn't mention how to obtain a valid worldHash or the return value, but those are not necessary for basic usage, especially given the sibling list_world_history_tool likely provides hashes. Overall, it is sufficiently complete for an agent to understand the tool's role.

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 adds meaning to worldHash by explaining 'content-addressable storage' and 'world pointer', implying worldHash is a reference to a prior state. However, it does not explicitly define projectId or the exact relationship between the parameters beyond what the names suggest.

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 action: 'Revert the synthesis theory to a prior world state.' It uses a specific verb and resource, distinguishing it from siblings like undo_last_operations_tool by framing the action as reverting to a specific state via a world hash.

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

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

The description implies when to use the tool (when a prior world state needs to be restored) but does not explicitly mention alternatives or exclusions. It does not compare with sibling tools such as undo_last_operations_tool or list_world_history_tool, so usage context is only inferred.

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 behavioral burden. It only states the action and that a summarized result is returned, but does not disclose side effects, resource requirements, runtime expectations, or any potential impact on the project. This is minimal transparency for a test-running 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 a single, succinct sentence that front-loads the core action and outcome. Every word is purposeful, with no extraneous information, making it appropriately concise.

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

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

Given the tool's complexity (6 parameters, 4 required), lack of annotations, and absence of an output schema, the one-sentence description is far from sufficient. It does not explain how parameters interact, what the 'summarized result' contains, or any operational context. An agent would be unable to correctly invoke the tool without additional information.

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

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

Schema description coverage is 0%, and the description does not explain any of the six parameters (projectId, commitSha, command, workingDirectory, regionId, framework). The description adds no meaningful information about parameter usage, formats, or valid values, leaving the agent without guidance on how to fill required inputs.

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 ('Run integration tests'), the resource ('for a project'), and the outcome ('return a summarized result'). This differentiates it from sibling tools like run_unit_tests_tool and run_mutation_tests_tool, 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 no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The only clue is the phrase 'integration tests', which implies a use case but does not directly compare with sibling tools or discuss suitable scenarios.

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 of behavioral disclosure. It does state that if 'tool' is not specified, auto-detection occurs based on project structure, and that it returns summarized statistics. However, it omits important behavioral traits such as potential side effects, execution time, or what happens to the report path.

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 three concise sentences with no filler. Each sentence adds value: purpose, supported frameworks, and auto-detection behavior. It is front-loaded and easy to scan.

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 7 parameters, 4 required, no output schema, and no annotations, the description is too sparse. It does not explain the required parameters (command, workingDirectory, etc.), the configuration of mutation tests, or the format of the returned statistics. A more detailed description is necessary for an agent to use it effectively.

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 should explain parameter meanings. It only adds context for 'tool' (framework support and auto-detection), leaving projectId, commitSha, command, workingDirectory, regionId, and reportPath unexplained. This does not sufficiently compensate for the lack of schema descriptions.

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

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

The description clearly states the tool's function: 'Run mutation tests and return summarized mutation statistics.' It uses a specific verb ('Run') and resource ('mutation tests'), and the mention of mutation testing distinguishes it from sibling tools like run_unit_tests_tool and run_integration_tests_tool.

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

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

The description implies when to use the tool ('Run mutation tests'), but it does not explicitly compare with alternatives or state exclusions. It provides some contextual detail about framework support and auto-detection, but no explicit 'use this over X' 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?

No annotations are provided, and the description only mentions 'summarized result' as a behavioral trait. It does not disclose execution side effects, required permissions, failure behavior, or output details.

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?

A single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose, though it lacks depth.

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 six parameters and no output schema or annotations, this sparse description is inadequate for correct tool invocation. It lacks parameter semantics, return value details, and usage prerequisites.

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

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

Schema description coverage is 0%, and the description does not explain any of the six parameters (command, workingDirectory, framework, etc.). The agent must infer meaning from parameter names alone.

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

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

The description uses a specific verb ('Run') and resource ('unit tests for a project'), clearly distinguishing it from sibling tools like run_integration_tests_tool and run_mutation_tests_tool. It also states the output type ('summarized result').

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 such as integration or mutation test runners. The description simply states the action without context 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Store' without addressing permissions, reversibility, what the response looks like, or how the evidence is integrated. The added context about grounding assertions is useful but insufficient for a mutation tool.

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

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

The description is two short sentences with no wasted words. It front-loads the core purpose and adds important context about the role of evidence. Every sentence earns its place.

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

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

Given five parameters, zero schema coverage, no annotations, and no output schema, the description is too sparse. It fails to explain parameter semantics, behavior on failure, or any side effects. For a tool with this complexity, more context is needed to guide correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It gives examples of evidence kinds ('test result, mutation result') but does not explain any of the five parameters (projectId, evidenceId, citation, kind, reliability). Parameters remain opaque, so the description adds minimal value over 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 uses a specific verb ('Store') and clearly identifies the resource ('evidence') and destination ('synthesis theory'). It distinguishes from siblings like add_assertion_tool by focusing on evidence storage rather than assertions.

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 phrase 'Evidence is required to ground assertions' gives clear context for when this tool should be used—whenever evidence needs to be recorded to support assertions. However, it does not explicitly state when not to use it or name alternatives, so it falls short of a 5.

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 of behavioral disclosure. It does not state that this is a read-only operation, how it handles incomplete or nonexistent runs, or any potential errors. The tool returns status data, but the lack of side-effect or error behavior disclosure is a notable gap.

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, concise sentence that front-loads the purpose and immediately lists the key return values. Every word contributes essential information without redundant filler.

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 single-parameter status tool, the description covers the core purpose and return contents. However, it omits edge-case behavior (e.g., what if the run is not completed or the ID is invalid) and does not explicitly state that it is a read-only operation, leaving some gaps in contextual 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%, and the description does not elaborate on the 'synthesisId' parameter. While the parameter name is self-explanatory, the description adds no extra meaning, such as where to obtain the ID (e.g., from list_synthesis_runs) or any format requirements.

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

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

The description uses a specific verb ('Check') and resource ('synthesis run'), and enumerates the returned data (iteration count, fitness history, counterexamples, outcome). This clearly distinguishes it from sibling tools like list_synthesis_runs (which lists runs) and cancel_synthesis (which cancels a run).

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

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

The phrase 'completed synthesis run' provides clear context for when to use this tool—after a run has finished. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear given the sibling tool names.

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. It reveals the internal approach ('LLM candidates + genetic algorithm evolution + counterexample feedback') and returns a 'SynthesisResult dict.' However, it does not disclose whether the synthesis runs synchronously or asynchronously, whether it modifies files, or how long it may take. The existence of sibling synthesis_status_tool suggests background execution, but that's not stated.

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

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

Three sentences, each with a purpose: state the action, describe the engine, and state the return type. No filler 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?

The tool has 11 parameters, 3 required, and no output schema or annotations. The description covers the overall goal and algorithm but omits parameter semantics, invocation context, return structure details, and lifecycle behavior. This leaves significant gaps for a complex 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 description coverage is 0% and the description does not mention any of the 11 parameters (e.g., projectId, workingDirectory, testCommand, targetMutantIds). It provides no guidance on required inputs or how to specify the target mutant, leaving the agent to guess from parameter names alone.

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 'Start' with the resource 'CEGIS synthesis,' clearly stating the goal: 'generate a patch that kills a surviving mutant.' This distinguishes it from sibling tools like synthesis_status_tool and cancel_synthesis_tool, which manage ongoing synthesis.

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 used when a mutant has survived and a patch is needed, stating 'to generate a patch that kills a surviving mutant.' It does not explicitly contrast with alternatives, but the context is clear that this starts synthesis, whereas siblings like synthesis_status_tool or list_synthesis_runs_tool query state. No exclusions are 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?

With no annotations, the description carries the full burden. It discloses the internal mechanism (walking the provenance DAG and rolling back), but does not mention side effects, irreversibility, error handling, or what happens if count exceeds available operations. Partial transparency.

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

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

Two sentences, front-loaded with the primary action, and no filler or redundancy. Every word contributes to understanding the tool's behavior.

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?

No output schema and no description of return values or failure cases. The description covers the core behavior but omits what the user can expect as a result (e.g., success status, new world state) and edge cases like an invalid 'count'. This is insufficient for a mutation 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 schema has 0% description coverage. The description implicitly explains 'count' as the number of operations (N), but it does not explicitly define 'projectId' or its role. It adds some meaning for count but leaves the required parameter underexplained.

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 a specific verb ('Undo') and resource ('belief revision operations'), with a scope (last N) and mechanism (walking the provenance DAG). This distinguishes it from similar tools like rollback_to_tool, which likely rolls back to an arbitrary state.

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

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

The description implies usage when the user wants to revert recent operations, but it does not explicitly state when to choose this tool over alternatives such as rollback_to_tool, nor does it mention exclusions or prerequisites. Clear context is present but not differentiated from siblings.

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 the full burden. It discloses supported backends (Z3, angr via Docker, mock), and that it returns a verification status and counterexample. However, it does not mention side effects, prerequisites, or whether it is read-only, leaving gaps in behavioral transparency.

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

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

The description is three sentences, front-loaded with the main action, and every sentence adds useful information: what it does, supported backends, and return values. There is no wasted text.

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

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

Given the tool's complexity (10 parameters, 0% schema coverage, no output schema, no annotations), this description is far from complete. It omits explanations of critical parameters like findKind/avoidKind, does not describe the output format in detail, and lacks guidance on prerequisites or failure modes.

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 10 parameters with 0% coverage, and the description only indirectly hints at backend, targetBinary, and constraints. Most parameters (entry, findKind, avoidKind, findValue, maxStates, avoidValue, timeoutSeconds) remain unexplained, leaving substantial ambiguity.

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 runs formal verification on a binary or constraint set, identifies supported backends, and specifies the return values (status and counterexample). This is a specific verb+resource, but it does not distinguish itself from the sibling verify_with_orchestrator_tool, so it loses the top score.

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

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

The description gives a clear context for when to use the tool: when formal verification is needed on a binary or constraint set. It does not explicitly mention alternatives or exclusions, but the usage context is apparent from the first sentence.

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 takes on the burden of behavioral disclosure. It reveals the budget escalation chain (10s → 30s → 120s) and the return shape (aggregated result with iteration history). This goes beyond simple 'run verification' but does not cover permissions, side effects, or error behavior.

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

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

The description is two sentences, front-loaded with the core function, and contains no filler. Every word 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 7 parameters with zero schema descriptions, no output schema, and no annotations, this description is too sparse. It explains the overall flow and return type but leaves parameter semantics and usage context entirely unaddressed, making it inadequate for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate by explaining the 7 parameters (entry, backend, findKind, findValue, constraints, targetBinary, maxIterations). It does not mention a single parameter, leaving the schema's titles and defaults as the only guidance. This is a critical 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 the CEGAR verification orchestrator with budget escalation, mentioning specific budget values (10s → 30s → 120s). This distinguishes it from sibling tools like verify_property_tool, which likely does single-shot verification.

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 verification with progressively larger budgets, but does not explicitly state when to use this tool versus alternatives such as verify_property_tool or list_verification_backends_tool. No when-not or exclusion criteria are 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?

With no annotations provided, the description carries the burden of behavioral disclosure. It states that the tool returns a list of evidence IDs that ground/support an assertion, which implies a read-only operation. However, it does not mention side effects, permission requirements, or behavior for missing/invalid inputs (e.g., non-existent assertionId), leaving some transparency gaps.

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

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

The description is two concise sentences that front-load the action and provide the key return value. There is no fluff or redundant phrasing, and every word contributes to understanding 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?

Given the simple two-parameter signature and lack of output schema, the description does a good job of explaining the return value (list of evidence IDs) and the core behavior. However, it omits details about project scoping, error cases, and how this tool differs from similar siblings, so it is not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter explanations. It only implicitly clarifies assertionId as 'a given assertion' and says nothing about projectId's role or acceptable formats. This is insufficient for an agent to confidently select and populate both required parameters.

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

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

The description uses specific verbs ('Trace', 'Returns') and clearly identifies the resource as the evidence chain for an assertion. It also includes the 'why do we believe this?' framing, making the purpose unambiguous. However, it does not explicitly differentiate from the similar sibling tool get_provenance_tool, so it misses the full top score.

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

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

The description implies usage when one needs to understand the evidentiary basis of an assertion, but it does not provide explicit when-to-use vs. when-not-to-use guidance or alternatives such as get_provenance_tool or belief_stability_tool. The context is clear but lacks exclusions or comparison to related tools.

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