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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the tool 'flags' deprecated calls but does not specify whether it modifies code, what output format is expected, or if it requires specific permissions. For a read-only analysis tool, this omission is significant.

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

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

The description is a single sentence with no unnecessary words, achieving high conciseness. However, it sacrifices clarity for brevity; a slightly longer description (e.g., specifying the source parameter and output) would improve informativeness without losing conciseness.

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

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

Given low schema coverage, no output schema, and no annotations, the description is insufficient. It does not explain the return format, error handling, or behavior when no deprecated calls are found. A more complete description would cover these aspects to guide the agent's invocation.

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

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

The sole parameter 'source' has no schema description (0% coverage), and the tool description does not clarify whether it expects a file path, code snippet, or string. The purpose implies MQL5 source code, but this is not explicit, leaving the agent to guess the expected input format.

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

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

The description uses a specific verb 'Flag' and identifies the resource as 'MT4-style deprecated API calls in MT5 source', clearly indicating the tool's purpose. It distinguishes from sibling lint tools by focusing on deprecated MT4-style calls, though it could explicitly contrast with other code analysis 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?

No guidance is provided on when to use this tool versus alternatives like syntax_check or lint_basic. The description does not mention prerequisites, typical use cases, or when not to use it, leaving the agent to infer usage from the name and 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 provided; the description covers the basic action but does not disclose additional behavioral traits such as whether it is a read operation, if it polls, or if it is non-blocking.

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?

Extremely concise: two sentences with no fluff. Every word serves a purpose, and the 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 lacks details about the return value (e.g., status types, elapsed duration format). Given no output schema, it should provide more context on what the response contains.

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

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

The description adds meaningful context for the single parameter job_id by stating it is the ID returned by start_job, which clarifies its source. With 0% schema coverage, this compensates well.

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 'Check' and the resource 'status and elapsed duration of a background execution job'. It distinguishes from sibling tools like start_job and get_job_result by specifying it checks status and duration.

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?

Indicates the job_id comes from start_job, providing context for when to use this tool. However, it does not explicitly state when not to use or mention alternatives.

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

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

No annotations are provided, so the description carries the full burden. It only states the basic action without disclosing any behavioral traits such as read-only nature, potential performance impact, or required permissions. It does not contradict annotations because none exist.

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

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

The description is a single sentence that is concise and front-loaded with the core purpose. No extraneous 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 description lacks details about output format, return structure, or performance considerations. With no output schema and no annotations, it is adequate for a simple tool but leaves some 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 description adds meaning by explaining that root is for processing all files under a directory and source is for a single file, but it does not explicitly map these to the parameter names. With 0% schema description coverage, this partial explanation compensates somewhat.

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 specifies the verb 'Compute' and the resource 'LOC/function/nesting metrics' for either a single file or all MQL files under a root. This clearly distinguishes it from sibling tools like lint_basic or syntax_check.

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 metrics are needed but does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it. No exclusions or alternative tools are mentioned.

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

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

No annotations are provided, so the description must fully disclose behavior. It only states the diffing operation but does not mention what happens on missing files, output format, size limits, or whether the operation is read-only.

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 of 13 words. It is front-loaded and efficient, though it could include a bit more detail without becoming overly verbose.

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

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

Given no output schema and no annotations, the description is incomplete. It lacks explanation of the return format, error handling, and any practical usage context that would help an agent 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%, so the description must compensate. It names the two parameters as baseline and candidate, but adds no additional detail about file paths, formats, or constraints. The titles are somewhat self-explanatory, but more context would be helpful.

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 diffs two MT5 tester HTML reports key-by-key with absolute and percent deltas. This is a specific verb-resource combination that distinguishes it from sibling tools like read_tester_report.

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

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

No explicit guidance on when to use this tool versus alternatives. While it's implied for comparing reports, there is no mention of prerequisites or context such as needing to read individual reports first.

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

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

No annotations are provided, so the description carries full burden. It transparently describes the compilation process, all parameters with defaults, and the return structure including errors, warnings, log excerpt, and command executed. However, it does not mention any potential side effects like file system writes beyond log files.

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 relatively concise, with a header and a bullet-like list for arguments and return values. It is front-loaded with the main purpose. However, the return structure could be better formatted for quick parsing.

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 (multiple parameters, structured return), the description is complete. It covers input parameters, defaults, and the full return structure including errors, warnings, log details, and command. No output schema exists, but the description compensates thoroughly.

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

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

With 0% schema coverage, the description fully compensates by explaining each parameter: 'source' as absolute path, 'include' as MQL root override with default, 'log_file' as explicit log path, and 'timeout_sec' as subprocess timeout with default 300. This adds significant meaning beyond the bare parameter names.

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 'Compile' and the resource '.mq4/.mq5/.mqh source via MetaEditor CLI'. It is specific and distinct from sibling tools like 'compile_and_deploy' which is a composite 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 does not explicitly state when to use this tool versus alternatives like 'compile_and_deploy'. It implies usage for standalone compilation but lacks guidance on 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?

No annotations are provided, so the description must disclose behavior. It does not cover failure handling (e.g., partial state on compile error), destructiveness (overwrites), permissions, or side effects. The chain operation's safety is unclear.

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

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

The description is a single sentence, front-loaded and direct. However, it is too brief to cover essential details; it earns its place but leaves gaps that could be filled without becoming overly long.

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 (combined compile+deploy) and no output schema, the description is insufficient. It does not explain the expected format of source, the role of ea_name, or what success/failure looks like. The agent may misuse parameters or misunderstand the workflow.

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

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

Schema description coverage is 0%. The description adds no meaning to parameters: 'source' and 'ea_name' are not explained. The agent cannot determine what values to provide or how ea_name affects deployment.

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: compile then deploy, specifies the output file types (.ex5/.ex4) and target directory (Experts/). It distinguishes from sibling tools like compile and deploy_ea by combining both steps.

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

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

No guidance on when to use this tool vs alternatives (compile, deploy_ea) or prerequisites (e.g., source file location, terminal selection). The agent must infer context from sibling 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?

No annotations are provided, and the description does not disclose behavioral traits such as whether it overwrites existing files, required permissions, or side effects. As a file operation tool, this is a significant omission.

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 brief with only two sentences plus a two-line parameter list. Every part is relevant, though it could benefit from a more structured format (e.g., bullet points).

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 file copy tool, the description covers the core functionality and parameters. However, it omits behavior on file overwrite, success feedback, and permissions, which leaves some gaps for an AI 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?

Despite 0% schema description coverage, the description explicitly explains the role of each parameter: source_ex as path to compiled binary, name as optional rename. This adds valuable meaning beyond the schema's type/title.

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

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

The description clearly states the action (copy) and the resource (compiled .ex4/.ex5 binary) and target (Experts/). It distinguishes from sibling tools like compile_and_deploy (which also compiles) and list_experts (listing).

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 compilation but does not explicitly state when to use this tool versus alternatives like compile_and_deploy, nor does it mention 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?

The term 'resolve' implies potential modification, but the description doesn't clarify if the tool is read-only or if it fixes issues automatically. With no annotations, the agent cannot determine side effects or safety characteristics.

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

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

The description is a single sentence that efficiently conveys the tool's purpose. However, it could be slightly more structured by front-loading the verb 'report' before 'resolve' to emphasize the primary action.

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

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

For a parameterless tool with no output schema, the description is minimal but adequate. It lists the key outputs (paths, hash, issues) but doesn't specify the return format or whether it reports errors versus successes.

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

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

The tool has no parameters, so the schema already conveys full coverage. The description adds value by explaining what the tool outputs (paths, hash, missing components), which is not redundant with the schema.

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

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

The description clearly identifies the tool's function: resolving and reporting MT4/5 paths, terminal hash, and missing-component issues. It uses a specific verb ('resolve and report') and resource names, making the purpose understandable. However, it doesn't explicitly distinguish from siblings like 'list_terminals' or other diagnostic 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?

No guidance is provided on when to use this tool versus alternatives like 'list_terminals' or 'compile'. The description lacks context for an agent to decide which tool is appropriate.

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

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

No annotations provided, so the description bears the full burden. It only states the extraction action without disclosing whether the file is modified, reading permissions, error behavior, or output format. Minimal behavioral context.

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

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

Single sentence, no extraneous words, front-loaded with verb and resource. Efficient.

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

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

For a simple one-parameter tool without output schema, the description is adequate but lacks clarity on the 'source' parameter and behavioral details like side effects. Could be more complete given no annotations.

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

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

Schema description coverage is 0%, and the parameter 'source' is not explained beyond being a file. The description implies a file path but does not specify format, whether it's local or remote, or any 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 verb 'Extract' and the specific resource: MetaEditor doc blocks with the exact pattern format. This distinguishes it from sibling tools like extract_function and extract_inputs.

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

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

No guidance on when to use this tool vs alternatives. It does not mention prerequisites, when not to use, or how it compares to similar extract tools.

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

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

The description discloses key behavioral traits: 'Brace-counting + regex param detection — not a full AST parser,' which alerts the agent to limitations. It also explains the dry_run flag and what the tool returns (proposed helper, call site, parameter list). With no annotations provided, this transparency is valuable.

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

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

Three concise sentences: purpose, methodology/return, and dry_run control. Front-loaded and no redundant information. 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 7 parameters, no output schema, and no annotations, the description provides a solid overview of purpose, methodology, return, and dry_run behavior. It does not detail every parameter or return format, but it is sufficient for a high-level understanding.

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

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

Schema coverage is 0%, so the description must compensate. It indirectly explains the required parameters (source, line_start, line_end, new_name) through context, but does not describe return_type or target_file. The description adds meaning for the core parameters but leaves gaps for optional ones.

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: 'Extract a contiguous block of lines into a new helper function.' It uses a specific verb (extract) and resource (contiguous block of lines, new helper function), and distinguishes well from siblings like extract_inputs or extract_doc which focus on different extraction tasks.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., extract_inputs, extract_doc, or manual refactoring). The description implies its use for code extraction but does not state prerequisites, limitations, or preferred 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?

No annotations provided. Description does not disclose any behavioral traits such as side effects, permissions, or output format. For a parsing tool, the return structure is critical but omitted.

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

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

Single sentence with no waste. However, could benefit from a brief example or additional context without becoming verbose.

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

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

No output schema, no annotations, and only one parameter with unclear semantics. The description is too minimal to enable effective use without further exploration.

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

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

Schema has 0% description coverage. Description says 'from a source file' but does not specify whether 'source' is a file path, file content, or other identifier. Ambiguous.

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

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

Description clearly states it parses 'input <type> <name> = <default>;' declarations, using specific verb and resource. Distinguishes from sibling 'extract_function' which extracts function declarations.

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 like 'gen_tester_inputs' or 'extract_function'. No mention of prerequisites or specific contexts.

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

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

No annotations provided, so the description must disclose behavioral traits. It only states the tool finds duplicates, but does not mention whether it is read-only, its performance impact, or any side effects.

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

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

A single sentence that is concise, but it could be improved by adding parameter explanations without becoming verbose.

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

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

No output schema, and the description does not explain what the tool returns (e.g., list of collision locations). Given low complexity, more detail is expected but missing.

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

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

Schema description coverage is 0%, and the description does not explain the parameters 'root' (required) or 'var_pattern' (optional). The agent cannot infer their meanings 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 clearly states the tool's action ('find') and specific resource ('duplicate magic-number assignments'), with a defined scope ('across the project'). It is distinct from the sibling tool 'find_symbol', which searches for symbol references.

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, nor any prerequisites or context. The description is purely functional without usage notes.

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 discloses a behavioral trait (skipping comments/string literals) but omits details like recursion, case sensitivity, or side effects. Adequate but not rich.

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, 11 words, front-loaded with core action and behavioral constraint. 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?

With 4 parameters, 0% schema coverage, no output schema, and no annotations, the description is too sparse to fully guide an agent. It lacks parameter details, return format, and error scenarios.

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

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

Schema description coverage is 0%, yet the description only implicitly mentions 'symbol' and 'root', ignoring 'exts' and 'limit' parameters. No explanation of acceptable values, constraints, or defaults beyond schema.

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

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

The description clearly states the action (grep), resource (symbol across MQL files), and a key behavioral constraint (skipping comments and string literals), distinguishing it from siblings like rename_symbol or code_metrics.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., code_metrics, lint_basic). There is no when-not-to or mention of prerequisites or 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?

Without annotations, the description fully discloses the non-destructive behavior ('without writing it'). However, no mention of permissions or edge cases.

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 with no wasted words. All information is front-loaded and essential.

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 or annotations; description omits return format, error conditions, and parameter details, leaving the agent with an incomplete understanding for a tool with two unannotated parameters.

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 the two parameters (source, style). The agent must infer meaning from parameter names only.

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 ('report') and resource ('whether a file needs formatting'), and distinguishes it from sibling tools like format_mql by emphasizing it does not write.

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

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

No guidance on when to use this tool versus alternatives (e.g., format_mql). Only implies it's a dry-run check, but no explicit 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?

The description reveals that the tool uses clang-format and treats source as C++, which is helpful. However, it omits critical behavioral details such as whether the tool writes changes to disk (the 'write' parameter defaults true), whether it returns formatted text, or any potential destructive actions. With no annotations, this gap is significant.

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 with no wasted words. However, it could benefit from additional structure, such as listing parameters or noting side effects, without becoming too long. The current brevity sacrifices completeness for conciseness.

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 (3 parameters, no output schema, no annotations), the description is too sparse. It does not explain the return value, the impact of the 'write' parameter, what happens on success/failure, or any dependencies. The agent lacks enough context to use the tool effectively 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?

The schema has 0% description coverage, meaning the schema itself provides no parameter explanations. The description fails to compensate by explaining the three parameters (source, style, write). It does not clarify valid values for style, the effect of write=false, or what source should contain. This makes it difficult for an agent to correctly construct arguments.

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: formatting an MQL file using clang-format, treating the source as C++. It specifies the verb, resource, and method, distinguishing it from sibling tools like format_check which only check formatting.

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

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

No guidance on when to use this tool vs alternatives like format_check or compile. The description does not mention prerequisites, typical use cases, or when not to use it. With many siblings, this lack of context reduces usefulness for agent selection.

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

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

Without annotations, the description carries the full burden. It discloses that it can append/replace in a file, but omits details about side effects, authorization needs, error handling, and the nature of 'EA inputs'. The behavioral disclosure is minimal.

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

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

Two sentences, 25 words, front-loads the core purpose. No redundant information. The conditional behavior is stated compactly. Excellent conciseness.

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 the description does not clarify the return value (e.g., does it return the generated block or only write to file?). The nature of 'source' is ambiguous, and potential failure modes are not addressed. Given the low parameter count and simplicity, more detail is expected.

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

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

Schema description coverage is 0%, and the description does not explain what 'source' represents (e.g., file path, string) or the required format. The 'write_to' parameter is mentioned but not fully defined. The description adds little value beyond the schema.

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

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

The description clearly states it generates a [TesterInputs] block from EA inputs. The verb 'Generate' is specific, and the resource is a configuration block. However, it does not explicitly distinguish this from sibling tools like 'extract_inputs' or 'patch_tester_ini', which could overlap.

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 over alternatives. The description only mentions a conditional behavior (if write_to points to tester.ini) but does not explain prerequisites, typical use cases, 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?

No annotations provided, so description carries full burden. It states 'retrieve' implying read-only, but fails to disclose failure modes (e.g., job not completed, invalid id), idempotency, or rate limits.

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

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

Two sentences: purpose and parameter explanation. No filler, front-loaded with the verb. Every sentence is necessary and efficient.

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

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

Missing crucial context: no output schema or description of return format, and no mention of preconditions (job must be complete). Despite having only one parameter, the tool's behavior is underspecified 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 has 0% coverage, but description explains job_id is returned by start_job, adding crucial context beyond the schema's type and title. This compensates for the empty schema 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 retrieves full structured results of a completed background job, specifying the action and resource. However, it does not explicitly differentiate from siblings like check_job_status or list_jobs, though the context implies it's for after completion.

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?

Minimal guidance: it mentions the job must be completed and the job_id comes from start_job, but no explicit when-to-use or when-not-to-use compared to alternatives like check_job_status.

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

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

No annotations provided, so description carries full burden. It only states the basic action (copy file) without disclosing side effects like overwrite behavior, permissions, or destination 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?

Very concise with one sentence and a bullet-like list of args. Every word adds value; no repetition 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?

For a simple copy tool, the description covers the core action and parameters. Lacks context on destination folder specifics and conflict handling, but is mostly adequate given the tool's simplicity.

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

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

Schema coverage is 0%, so description must compensate. It explains source is 'absolute path' and target_name is 'optional rename', adding meaning beyond the schema's type-only fields. However, it lacks details like expected format for target_name.

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 copies a .mqh file into the terminal Include folder, with a specific example. This verb+resource combination distinguishes it from sibling tools like compile or deploy_ea.

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

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

No guidance on when to use this tool vs alternatives like resolve_includes or compile_and_deploy. The description does not mention prerequisites or exclusions.

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

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

No annotations provided. The description omits behavioral traits such as file modifications, overwriting behavior, success/failure signals, or required file structure. The agent cannot predict side effects.

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

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

The description is very short (two sentences plus args) and directly readable. However, some behavioral details could be added without harming conciseness, keeping it 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?

The description covers the core purpose and parameter but lacks completeness for a file-modifying tool. No mention of return values, side effects, or success conditions. Given no output schema, more context would be beneficial.

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

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

With 0% schema description coverage, the description adds meaning by specifying 'Absolute path to the .mq5 file' for the sole parameter ea_path. While brief, this clarifies the parameter role beyond the schema's type-only definition.

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

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

The description clearly states the tool's function: automatically instrument an MQL5 Expert Advisor (.mq5) file with OptExport.mqh logging. The verb 'instrument' and resource are specific, distinguishing it from sibling tools like compile or deploy.

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, no prerequisites or exclusions. The description lacks context about the tool's place in the workflow, leaving the agent to infer usage from the name and 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?

No annotations exist, so description must fully disclose behavior. It states 'force-kill all running terminal processes' but does not mention side effects (e.g., unsaved work loss) or if any confirmation is needed. The destructive nature is clear but incomplete.

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, concise, and to the point. Every word serves a purpose.

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

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

For a simple zero-parameter destructive tool, the description is adequate but could be more complete by noting edition scope or recovery options. No output schema or annotations to supplement.

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

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

There are no parameters and schema coverage is 100%. The description accurately reflects the tool takes no arguments, so no additional detail is needed.

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 ('Force-kill all') and resource ('running terminal processes for the configured edition'), clearly distinguishing it from siblings like list_terminals or select_terminal.

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

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

No guidance on when to use this tool vs alternatives (e.g., graceful shutdown, or killing specific terminals). The description implies it's a brute-force kill, but doesn't state prerequisites or consequences.

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

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

No annotations provided, so description carries full burden. It lists rules but fails to disclose side effects, output format, or whether it is read-only. For a lint tool, expected behavior is undocumented.

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 with no redundancy, but omits critical information (parameter, output, usage context). Conciseness does not compensate for incompleteness.

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?

Description is too sparse for a simple tool. Lacks explanation of parameter, output, and operational context. Not sufficient for an agent to correctly invoke the tool.

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

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

Parameter 'source' has no description in schema (0% coverage) and description does not explain its meaning (e.g., file path, code string). Agent cannot infer how to provide input.

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

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

Description clearly states the tool runs structural lint rules and lists specific checks (missing handlers, unused inputs, hardcoded magic/symbol). It distinguishes from siblings like syntax_check by focusing on structural issues, but could further differentiate.

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

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

No guidance on when to use this tool versus alternatives (e.g., syntax_check, check_deprecated) or when not to use it. Context is missing.

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

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

No annotations exist, so the description carries full burden. It only states the action without disclosing behavioral traits such as read-only nature, performance implications, or authorization needs. 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 a single sentence, which is concise. However, it lacks structure and does not fully earn its place, as it omits critical details about parameters and usage.

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 two parameters (pattern, recurse) and no output schema, the description should explain these and the output format. It fails to do so, leaving the agent underinformed.

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

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

Schema description coverage is 0%, and the description does not explain the 'pattern' or 'recurse' parameters. An agent cannot infer how to use these parameters from either source, making the tool unreliable.

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

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

The description clearly states the tool lists compiled EAs in the Experts directory. The verb 'list' and resource 'compiled EAs in Experts/' are specific. However, it does not differentiate from sibling tools, though none appear to have similar functionality.

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

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

No guidance on when to use this tool versus alternatives. The description provides no context about usage scenarios or limitations. An agent receives no help deciding when to invoke it.

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

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

No annotations provided, so the description must fully disclose behavioral traits, but it only states it lists jobs and describes parameters. It omits details like pagination, sorting, or any side effects.

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

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

The description is brief with a clear first sentence stating purpose, followed by concise parameter explanations. No unnecessary 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 simple tool (2 optional params, no output schema), the description adequately covers purpose and parameters, but lacks information on response format, default limit, or maximum limit.

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

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

Despite 0% schema description coverage, the description explains both parameters: 'limit' with default and meaning, and 'status' with example values, adding value beyond the raw schema.

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

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

The description clearly states 'List recent Strategy Tester execution jobs tracked in the database,' specifying the verb (list) and resource (jobs), and distinguishes from sibling tools like start_job and check_job_status.

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

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

No explicit guidance on when to use this tool versus alternatives, no when-not-to-use instructions, and no mention of prerequisites or context for invocation.

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 full burden. It implies a read operation but does not explicitly state non-destructive behavior, permissions needed, or any side effects. This is insufficient 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?

A single sentence that conveys the essential purpose without any wasted words. Very concise and well-structured.

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

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

For a simple tool with one parameter and no output schema, the description is adequate but lacks details on output format, error handling, and differentiation from sibling tools. It covers the basics but could be more 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, so the description must compensate. It adds that 'dest' is a directory under which snapshot folders are listed, but provides no further detail on expected format, constraints, or behavior. This adds marginal value beyond the schema.

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

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

The description clearly states the action (list) and the resource (snapshot folders) with a location constraint ('under dest'). It distinguishes from sibling tools like snapshot_sources by specifying the scope (folders under a given path).

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 like snapshot_sources. The description does not provide any context for when this tool is appropriate or when other tools should be used instead.

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 fully disclose behavior. It correctly describes a read-only enumeration operation, but does not mention access requirements, performance, or output format. While adequate for a simple tool, it 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?

A single sentence that is front-loaded with the key verb and resource, containing no fluff. Every word earns its place.

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

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

For a parameterless, simple enumeration tool, the description is nearly complete. It lacks only a brief mention of the return format (e.g., list of folder paths), but the context is sufficient for basic use.

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, and schema coverage is 100%. The description adds context about the specific directory path, which is useful. Baseline for 0 parameters is 4, and the description meets that adequately.

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 ('Enumerate') and resource ('MetaTrader terminal data folders'), with an exact file path, making the tool's purpose crystal clear. It is distinct from sibling tools like 'list_experts' or 'list_snapshots'.

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, no prerequisites, and no exclusions. It simply states the function without contextual usage advice.

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 present, so the description must disclose behavioral traits. It labels the tool as 'best-effort' and 'unreliable' and describes the two parsing modes (latest vs. given path). However, it omits important details like return format, error behavior, and side effects, leaving gaps despite the clear safety warning.

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: the first delivers the critical legacy warning and alternative recommendation, the second explains functionality. No redundant information, perfectly 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?

With one parameter, no annotations, and no output schema, the description covers core purpose and alternative but lacks details on return values, error handling, and the exact format of output. For a parser tool, these are significant gaps, though the legacy status reduces the need for completeness.

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

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

The input schema for 'path' has zero description coverage, but the description adds meaning by explaining that omission parses the latest file and providing a path parses a specific file. This compensates well for the schema gap, though it could specify path format more precisely.

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 explicitly states the tool parses binary .opt files (verb+resource) and distinguishes it from the recommended read_optimization_csv sibling, clearly indicating its legacy status.

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

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

The description provides explicit guidance on when to prefer the alternative (read_optimization_csv) over this tool, fulfilling the dimension's criteria for when-to-use and alternatives.

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

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

With no annotations, the description carries full burden. It discloses the in-place mutation and return type, but lacks details on file existence handling, permissions, backup, or error behavior. Adequate but not comprehensive.

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

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

The description is short (3 lines) with clear Args/Returns structure. Every sentence is essential and front-loaded. No wasted words.

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

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

Given 2 parameters and no output schema, the description adequately covers inputs and output. Could mention file existence or backup, but is largely sufficient for a simple 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?

Schema description coverage is 0%, so the description compensates fully: it explains config as a path and updates as Section.Key→value mapping with a concrete example. This adds critical meaning beyond the bare schema types.

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 updates fields in a tester.ini file in-place, specifying the verb (update), resource (tester.ini), and nature (in-place). This distinguishes it from sibling tools like validate_tester_ini or gen_tester_inputs.

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

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

The description implies use when modifying tester.ini fields, but does not explicitly state when to use this tool versus siblings or provide when-not scenarios. It relies on the agent inferring from the name and 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?

The description states the tool reads a CSV file, implying a read-only operation. No annotations are provided, so the description carries the full burden. It does not disclose potential failures (e.g., file not found), file location constraints, or side effects. The behavioral disclosure is adequate but minimal.

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

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

The description is concise and well-structured. It opens with a clear one-sentence summary of the tool's purpose, then lists parameters in a conventional Args format. Every sentence adds value with no redundancy. The length is appropriate for the tool's simplicity.

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

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

Given that there is no output schema and schema description coverage is 0%, the description covers the input parameters well. It explains the source file, sorting, and row limit. Missing details include the structure of the returned data (e.g., which fields are present) and error handling. However, for a straightforward read operation, this is mostly 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 description thoroughly explains each parameter: run_id is required and specifies the run ID; top_n controls the number of passed; criterion defines the sort column; descending sets sort order. This adds meaning beyond the schema, which only provides types and defaults. Schema description coverage is 0%, so the description fully compensates.

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

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

The description clearly states the tool reads optimization results from a specific CSV file generated by OptExport.mqh in Common Files folder. It uses a specific verb ('Read') and resource ('optimization_results from CSV file'). However, it does not explicitly differentiate from sibling tools like parse_optimization or top_passes, which may have overlapping functionality.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., parse_optimization, top_passes). No prerequisites, typical use cases, or when-not-to-use information is included. The agent must infer the tool's role from the 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?

With no annotations, the description carries the full burden. It discloses that the tool locates and parses the report and returns raw HTML (implied by the 'raw_truncate' parameter and later mention of 'raw HTML returned'). However, it lacks details on error behavior (e.g., if no report is found), return format beyond raw HTML, or any side effects. This is adequate but incomplete.

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

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

The description is very concise with two short paragraphs: one for overall purpose and one for argument descriptions. It is front-loaded with the main purpose and contains no fluff. Every sentence adds value.

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

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

The tool has no output schema, so the description should hint at return values. The 'raw_truncate' parameter implies raw HTML is returned, but the term 'parse' suggests structured output, creating ambiguity. No explicit mention of output structure or error handling leaves the agent needing to infer. For a simple tool, this is minimally sufficient but not 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%, so the description must compensate. It explains that 'path' can be an explicit path or omitted to find the latest file in Tester/, and 'raw_truncate' limits raw HTML characters. This adds meaning beyond the schema's type and default values, effectively covering both parameters.

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

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

The description clearly states 'Locate and parse latest MT5 tester HTML report', which includes a specific verb (locate and parse) and resource (MT5 tester HTML report). However, it does not explicitly differentiate from sibling tools like 'read_optimization_csv' or 'compare_reports', so a high score but not 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?

No guidance is provided on when to use this tool versus other sibling tools (e.g., read_optimization_csv for CSV reports). The description only explains what the tool does without any context about appropriate usage scenarios or when to choose an alternative.

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 implies a read-only operation ('verify') but does not confirm side effects, error handling, return values, or permissions. The description adds no behavioral detail beyond the basic purpose.

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 with no wasted words. However, it is too terse for the tool's complexity, lacking essential details. While concise, it sacrifices completeness.

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 3 parameters, no output schema, and no annotations, the description is insufficient. It does not explain the format or semantics of parameters, the nature of the output, or how guard thresholds are defined. Important gaps remain.

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

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

The input schema has 0% parameter description coverage, so the description must compensate. It mentions 'guard thresholds' hinting at the 'guards' parameter but fails to define what 'baseline' and 'candidate' are (e.g., IDs, file paths) or the structure expected in 'guards'. This provides minimal additional meaning beyond the parameter names.

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: to verify that a candidate report does not exceed guard thresholds relative to a baseline. The verb 'verify' and the specific resource 'candidate report vs baseline' are well-defined. However, it does not explicitly distinguish itself from the sibling tool 'compare_reports', but its focus on thresholds provides implicit differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'compare_reports', nor does it mention prerequisites, failure scenarios, or when not to use it. It only states what it does without 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 exist, so description must cover behavioral traits. It mentions whole-word match and dry_run, but does not state whether renaming is destructive, backs up files, or requires permissions. Effects on multiple files or partial matches are not 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?

Two concise sentences with no fluff. The core functionality is front-loaded, and the second sentence adds a key usage note. Every sentence adds value.

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

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

The tool modifies files, but the description lacks context on return values, error handling, or what happens on conflicts. With no output schema and no annotations, more completeness is needed to fully inform usage.

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

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

Schema coverage is 0%, so description must explain parameters. It only describes dry_run (preview). Old, new, and root are mentioned by name but their meaning (e.g., symbol names, directory path) is not 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 states the action (rename), the resource (a symbol across MQL files), and a key constraint (whole-word match). It distinguishes from siblings like find_symbol by indicating an active change 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 (when renaming a symbol) but lacks explicit guidance on when not to use or alternatives. The dry_run preview is mentioned, but no comparisons to other tools are provided.

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

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

No annotations provided, so description must disclose behavior. It mentions recursion and reporting unresolved files, but fails to state side effects (e.g., file modifications), error handling, or return format. For a tool with no annotations, this is insufficient.

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

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

Two short sentences with no fluff, achieving brevity. However, the conciseness sacrifices necessary detail; a third sentence on parameters or usage would improve it without bloating.

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 2 parameters, no output schema, and no annotations, the description is too sparse. It lacks details on return value (e.g., list of resolved files? count?), behavior when all includes resolve, or error conditions. Agent lacks enough info to use confidently.

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

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

With 0% schema description coverage, the description should explain parameters. It does not clarify what 'source' (file path?) or 'mql_root' (base directory?) mean, leaving the agent to guess. The default value of null for mql_root is unexplained.

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

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

The description clearly states the action ('Recursively resolve #include directives') and the output ('Reports unresolved files'), making the tool's purpose specific and distinct from siblings like compile or install_include.

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

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

No explicit guidance on when to use vs alternatives (e.g., compile also resolves includes). The description implies usage for checking includes, but lacks context on prerequisites or when to prefer this over other tools.

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

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

The description discloses blocking behavior (wait flag), timeout, and portable flag. It mentions that wait requires ShutdownTerminal=1 in the ini file. However, with no annotations, it lacks details on side effects, permissions, or return value semantics.

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

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

The description is concise with a brief intro, bulleted args, and return values. It's front-loaded with the main purpose. It could be slightly more structured (e.g., grouping return fields), but overall efficient.

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

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

With 4 parameters, no output schema, and no annotations, the description covers purpose, args, and return. It lacks error handling, prerequisites, and relationship to sibling tools, but is adequate for basic usage.

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

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

Schema coverage is 0%, but the description adds meaning: config is absolute path, wait blocks until exit, timeout_sec is wait timeout, portable passes the /portable flag. This significantly compensates for the schema's lack of 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 it launches a terminal with a tester.ini config to run backtests. The verb 'Launch' and resource 'terminal with /config:<tester.ini>' are specific, but it doesn't explicitly distinguish from related tools like 'start_job' or 'compile'.

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 like 'start_job' or 'smoke_test'. The description only explains what it does without providing context for selection.

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

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

No annotations provided, so description bears full burden. It discloses that the switch affects subsequent tool calls and persists until server restart. It also explains the install auto-scan behavior. Minor omission: no mention of error conditions or required permissions.

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

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

The description is concise (4 sentences), front-loaded with the main action, and each sentence adds unique value. No wasted words.

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

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

Given no annotations, no output schema, and 4 parameters, the description adequately explains the tool's purpose and scope (session persistence). Lacks guidance on parameter combinations or error handling, but sufficient for a simple state-change 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%, but the description adds meaning for three key parameters (origin, hash, install) by explaining their roles. The `edition` parameter is mentioned but not described, slightly reducing completeness.

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 switches the active terminal data folder for the session, specifying three modes (origin, hash, install). This distinguishes it from siblings like list_terminals or kill_terminal.

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

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

The description explains how to use the parameters but does not explicitly state when to prefer this tool over alternatives like list_terminals to view available terminals. Usage context is implied but not contrasted with 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?

No annotations are present, so the description must carry the full burden. It lists steps and the success condition, but lacks details on side effects (e.g., file cleanup), failure behavior beyond returning false, and required environment state (e.g., terminal selection). This is insufficient for a composite operation.

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 efficiently conveys the core purpose and success condition. It is front-loaded but could be slightly more structured. Every sentence adds value with no redundancy.

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

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

Given the tool's complexity (6 parameters, multi-step operation, no output schema, no annotations), the description is inadequate. It omits prerequisites (e.g., terminal state), error handling details, cleanup behavior, and parameter constraints. The agent would need external knowledge to use it reliably.

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

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

Schema description coverage is 0%. The tool description only mentions a '1-day' backtest, which hints at the days parameter, but does not explain the other five parameters (source, symbol, expert_name, period, timeout_sec). The agent cannot infer correct parameter values from the 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 performs compilation, deployment, running a backtest, and journal scanning. It explicitly defines the verb ('smoke test') and the resource (the combined steps). This differentiates it from sibling tools like compile, run_backtest, and deploy_ea which handle individual steps.

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 quick validation, but does not explicitly state when to use it instead of alternatives or when not to use it. No guidance on prerequisites or exclusions is provided.

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

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

No annotations are present, so the description bears full responsibility. It mentions 'freeze' and 'timestamped folder' but omits details on file overwrites, recursion, directory structure preservation, side effects, or required permissions.

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

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

The description is a single, efficient sentence with no wasted words. However, it may be too terse given the lack of other contextual support from schema or annotations.

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

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

Given no output schema, no annotations, and three parameters with zero schema descriptions, the description is severely incomplete. It fails to explain return values, label behavior, or source path handling.

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 clarify parameters. It partially explains dest and sources but omits label entirely. No format or constraints are given for the sources array.

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 ('freeze a copy'), the resource ('source files'), and the destination ('timestamped folder under dest'). It effectively distinguishes the tool from siblings like list_snapshots or compile.

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

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

No guidance is provided on when to use this tool versus alternatives, prerequisites, or when not to use it. With many sibling tools, explicit usage context is lacking.

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 description is the sole source. It discloses the key behavioral trait 'non-blocking', but does not mention side effects, error handling, or how to retrieve results later.

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 plus args list, no fluff. Purpose is front-loaded, and parameter descriptions are clear and concise.

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

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

Covers purpose and parameters adequately, but lacks mention of output or next steps (e.g., monitoring job status). Given no output schema and simple tool, it is minimally complete but could include more context.

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

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

With 0% schema description coverage, the description compensates well by explaining both parameters: config as absolute path to .ini file, kind as execution type with allowed values. Adds meaningful context beyond schema.

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

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

The description clearly states it starts a non-blocking backtest or optimization run, using specific verb 'Start' and resource 'Strategy Tester run'. It distinguishes itself from sibling like 'run_backtest' by specifying 'non-blocking'.

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

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

Implied usage through 'non-blocking' suggests when to use versus a blocking alternative, but no explicit exclusions or alternatives are named. Does not guide on when not to use or prerequisites.

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 syntax-only mode and diagnostics return, but lacks details on side effects, safety, permissions, or error handling. 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?

Single sentence, efficient and front-loaded with the verb and resource. Every word earns its place.

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

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

No output schema exists, yet the description only vaguely mentions 'return diagnostics' without format or content details. Parameter descriptions are missing. Adequate for a simple tool but incomplete for full understanding.

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 what 'source' should contain (file path or code string) or the meaning of 'timeout_sec'. The schema provides basic type/default info, but the description adds no value.

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

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

The description clearly states the tool compiles source code in syntax-only mode and returns diagnostics. It specifies the mode `/s` and the resource 'source', distinguishing it from siblings like 'compile' and 'lint_basic'.

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 syntax checking only, but does not explicitly state when to use this tool over alternatives like 'compile' or 'lint_basic'. No exclusions or prerequisites are mentioned.

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

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

No annotations provided, so description must disclose behavior. It accurately describes reading logs (non-destructive) and parameter effects. It does not mention limitations like file existence or permissions, but for a simple read operation, this 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 extremely concise with a clear Args section and bullet points. Every sentence adds value; no filler 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?

With 4 parameters, no annotations, and no output schema, the description covers all necessary aspects. It explains all parameters and their defaults. The return format is implied (lines of text), but a brief note on output could improve completeness.

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

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

Schema description coverage is 0%, but the description adds full meaning: explains mode values ('live', 'journal', 'tester'), lines count, date override, and structured parsing. This compensates completely for the missing 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 'Read last N lines from terminal logs,' specifying a verb and resource. It differentiates modes (live, journal, tester), distinguishing it from sibling tools like list_terminals or compile.

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

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

The description explains parameter usage (mode, lines, date, structured), providing clear context for when to use each. It lacks explicit when-not or alternatives, but the sibling set is diverse and tail_log is unique.

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

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

No annotations exist, so description must carry the burden. It warns of being 'best-effort' and 'unreliable' but does not disclose specific failure modes, error handling, or side effects.

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

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

Two concise sentences, with the critical legacy warning front-loaded. No wasted words; every sentence adds value.

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

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

No output schema exists, yet description fails to explain return format or behavior on failure. Given 4 parameters and no nested objects, deeper context on usage and outcomes is missing.

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

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

Schema coverage is 0%, so description should detail parameters. It only mentions 'criterion' and 'top N' implicitly; no explanation of n, opt_path, criterion values, descending behavior, or defaults.

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 parses binary .opt files, sorts by criterion, and returns top N. It explicitly names the preferred alternative (read_optimization_csv), distinguishing from siblings.

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

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

Explicitly states it is legacy, unreliable, and advises using read_optimization_csv instead. This provides strong when-to-use and when-not-to-use guidance.

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

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

Without annotations, the description must fully disclose behavioral traits. It only states the action (sanity-check, conditional cross-check) but omits details like read-only nature, error handling, side effects, or output format. The description is too sparse for an agent to understand the tool's behavior beyond its basic purpose.

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

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

The description is highly concise: two sentences with no extraneous words. The core action and conditional behavior are front-loaded, making it easy for an agent to quickly grasp 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?

Given the lack of output schema, annotations, and parameter descriptions, the description is incomplete. It fails to specify the return value (e.g., validation errors or success), input format for `config`, or any post-conditions. A more complete description would address these gaps for a tool with this complexity.

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

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

With 0% schema description coverage, the description must explain parameters. It only addresses `source` (optional, triggers cross-check) but does not describe `config` (required string), leaving its meaning ambiguous. The schema provides no additional hints, so the agent is left guessing about the `config` parameter's content or format.

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

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

The description clearly states the tool performs a 'sanity-check' on a tester.ini file and optionally cross-checks against EA declarations when `source` is provided. This defines the verb and resource, and distinguishes it from sibling tools like patch_tester_ini (which modifies) and gen_tester_inputs (which generates). However, 'sanity-check' is slightly vague; specifying validation criteria would improve 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 implies usage contexts: validation of tester.ini alone or with a source for cross-referencing. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the many sibling tools. The conditional behavior is a helpful hint but insufficient for optimal tool selection.

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