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

Annotations already declare the tool read-only and idempotent; the description adds that it performs static analysis without invoking the compiler, so no compile artifacts or compiler errors are produced. It also reveals that the deprecated check includes MT5 replacements, not just a list of issues. There is no contradiction with annotations.

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, no filler: the first is front-loaded with core behavior and scope, and the second gives routing guidance. 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?

For a three-parameter tool with a full input schema, an output schema, and read-only/idempotent annotations, the description covers purpose, scope, check semantics, and the key alternative. The only implied detail, that root is metrics-only, is already supplied by the schema's parameter description.

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

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

All three parameters are described in the schema with 100% coverage, so the description does not need to re-explain root/source/checks. It does add meaning for the checks enum by explaining what 'lint', 'deprecated', and 'metrics' actually cover, while the schema handles the file/folder distinction.

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

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

The description uses a specific verb ('analyze') and resource ('MQL source'), explicitly scopes it to 'without compiling', and enumerates the three check families: structural lint, deprecated API calls with MT5 replacements, and size/nesting metrics. This clearly distinguishes it from compile and from the legacy lint/deprecated/metrics 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?

It explicitly says it 'Replaces lint_basic / check_deprecated / code_metrics', telling the agent not to use the older siblings for these checks. It also routes compiler diagnostics to `compile(syntax_only=true)`, giving an explicit alternative condition.

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?

Annotations already flag the operation as destructive (destructiveHint=true), and the description adds specifically what gets destroyed—the terminal of a running background backtest—and the subsequent outcome that no report is produced. This goes beyond the bare annotation and gives the agent an important behavioral consequence.

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 filler. The action and object are front-loaded, and the second sentence delivers only the critical consequence. 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 simple one-parameter destructive tool with a full input schema and an output schema, the description covers the core action and the important outcome of a cancelled run. A minor gap is the absence of any statement about the behavior if the backtest is not actually running, but this is not a blocker for correct invocation.

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

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

The run_id parameter is fully described in the schema, including its provenance as the identifier returned by start_backtest/run_backtest. Since schema description coverage is 100%, the description does not need to add parameter details, and the baseline score of 3 is appropriate.

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

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

The description opens with a specific action ('Kill the terminal') and a precise target ('a running background backtest'), then adds the key consequence that no report is produced. This clearly distinguishes the tool from reading, listing, and starting backtests, even without naming a sibling.

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 intended use case: a background backtest that is currently running and needs to be terminated. However, it does not explicitly contrast itself with the related sibling kill_terminal or explain when to choose this over that tool, leaving the routing partially to the agent's inference.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that the tool is removed in 0.6.0, which is useful behavioral context beyond annotations because it warns that execution should be avoided. It does not describe the old tool's behavior, but that is unnecessary for a deprecated stub.

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 entire description is one compact sentence, front-loaded with DEPRECATED and ending with the precise replacement call. Every part earns its place and there is no filler or redundant restatement of the schema.

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 deprecated tool, the context is complete: annotations cover safety, the schema covers the parameter, and the description names the replacement and the removal version. An output schema exists, so return-value documentation is not needed. An agent has everything required to decide how to handle this tool.

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

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

The schema fully documents the single parameter as an absolute Windows path to a .mq4/.mq5/.mqh source file, so schema coverage is 100%. The description only references the source argument in the replacement call and adds no new parameter-level semantics. The baseline of 3 is appropriate because the schema already carries the meaning.

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

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

The description immediately marks the tool as DEPRECATED and removed in 0.6.0, making its status unmistakable. It then names the exact replacement call, analyze_mql(source, checks=['deprecated']), which distinguishes it clearly from the analyze_mql sibling and tells the agent not to select this 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 explicitly says to use analyze_mql(source, checks=['deprecated']) instead, leaving no ambiguity about when this tool should be used: never. It provides both the exlusion condition (deprecated/removed) and the exact alternative with required arguments.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate safety. The description adds the key behavioral fact that this tool is deprecated and removed in 0.6.0, which is valuable context beyond the annotations. No contradiction exists between the description and annotations.

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 entire description is one sentence with the deprecation warning front-loaded and the replacement instruction following immediately. There is no redundant wording or filler, matching the standard for an effective concise tool description.

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 deprecated tool, the description is complete: it warns against usage, names the replacement, and gives the replacement invocation. Safety is fully covered by annotations, and an output schema exists, so return values need no additional description. Nothing essential is missing for an agent to act 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 coverage is 100%, so root and source are already documented as an absolute folder and an absolute file path. The description adds semantic value by showing how these parameters map into the replacement call: analyze_mql(source or root, checks=['metrics']). This goes slightly beyond the schema and helps the agent migrate usage.

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 identifies the tool as deprecated and immediately redirects to analyze_mql with checks='metrics', which conveys the tool's former purpose by reference. It does not state a direct verb+resource for code_metrics itself, but the deprecation notice makes the intended action clear. This is sufficient for an agent deciding whether to invoke it.

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

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

The description gives explicit usage guidance: do not use this tool, use analyze_mql instead. It even provides the exact replacement call pattern, including the source or root argument mapping. This is strong when-to-use/when-not-to-use guidance with a named 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?

Annotations already cover read-only and idempotent behavior. The description adds useful guard semantics and a caution about selection bias, but it does not disclose deeper behavioral details like output size, performance, or whether files are consulted beyond what the schema implies.

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 main purpose is stated in one crisp sentence, with a focused second paragraph elaborating on guard semantics. The caveat about selection bias is relevant, though slightly tangential to simply invoking the tool.

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

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

With an output schema present and annotations covering safety, the description provides enough context to know when to combine variables. It explains the optional guard behavior and its interpretation, covering the essential decision space.

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 covers all parameters, but the description adds key meaning. Specifically, it explains that profit-style metrics below a threshold and drawdown/loss metrics above are violations, going beyond the schema's 'percent thresholds per summary key'.

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

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

The description opens with 'Diff two tester reports key by key (absolute and percent deltas)', which uses a specific verb and resource distinctly. It also explicitly says 'Replaces regression_check', differentiating it from a sibling 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 states it is the replacement for regression_check, giving clear guidance on which sibling to use. It also frames when to use guards and how to interpret thresholds, though it does not enumerate contexts where other comparison tools should be preferred.

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?

Beyond the annotations, the description explains the exact success condition (`ok` requires a `Result:` line with 0 errors, plus a fresh binary unless syntax_only), the `binary_fresh` concept, expected duration (1–30 s), and that warnings do not block deployment. This is substantive behavioral disclosure.

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

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

The description is compact, front-loaded with the core purpose, and every sentence earns its place: success semantics, retry guidance, timing, and the sibling alternative. 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?

Given the rich output schema and fully documented parameters, the description covers all essential operational context: success criteria, error handling, timing, binary freshness, and the deployment alternative. The agent has everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds a little semantic context around `syntax_only` and `timeout_sec` via the duration note, but does not meaningfully extend the schema's own parameter documentation.

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

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

Opening sentence names a specific action ('Compile one MQL source') and the tool context ('with MetaEditor'), and the final sentence distinguishes the sibling compile_and_deploy. The purpose is immediately clear and non-tautological.

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

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

The description gives clear guidance on when to call this tool versus compile_and_deploy, and instructs the agent to fix errors and retry. It does not explicitly mention the sibling syntax_check tool, though the syntax_only parameter partially covers that use case.

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?

Annotations already mark this as destructive and non-idempotent, so the bar for extra behavioral disclosure is lower. The description adds valuable conditional behavior: deploy only happens after successful compile, and `ok` is false if either stage fails, with compile errors surfaced in `compile.errors`.

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 short sentences, each earning its place: the core operation, the intended usage context, and the return/error semantics. The most important information is front-loaded.

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

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

For a two-stage tool with an output schema and destructive annotations, the description covers the essential sequence, failure behavior, and when to use it. It could mention that deploying may overwrite an existing binary, but the annotations already signal destructiveness, so this is not a major gap.

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

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

Schema description coverage is 100%, so the schema already documents both `source` and `ea_name`. The description adds no new parameter-level detail beyond naming the source as the thing compiled, so the baseline 3 is appropriate.

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 names a specific verb and resource: compile a source and, on success, copy the binary into Experts/. It clearly distinguishes itself from siblings like `compile` or `deploy` by describing the combined two-stage operation and the resulting deploy location.

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

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

It explicitly states when to use the tool: before `run_backtest` or `smoke_test`. It does not, however, tell the agent when to prefer standalone `compile` or `deploy` instead, so the guidance is clear but not fully contrastive.

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 explicitly discloses that the operation 'Overwrites an existing file of the same name,' which is important destructive behavior beyond the destructiveHint annotation. It also clarifies that the target directory is determined by file extension, adding behavioral detail not present in the annotations.

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

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

The description is two sentences with no filler. The primary behavior and extension routing are front-loaded, and the second sentence adds the critical overwrite warning and the compile_and_deploy alternative efficiently.

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

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

Given the simple two-parameter API, destructive annotation, and output schema presence, the description covers the essential behavior, the overwrite risk, and the main alternative workflow. It could mention behavior for unsupported extensions, but that is a minor gap.

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

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

Schema description coverage is 100%, so the file and name parameters are already well documented. The description adds context about extension-based routing but does not materially extend the parameter-level meaning beyond what the schema already provides.

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

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

The description states a specific action ('Copy'), a precise resource ('compiled EA' or '.mqh header'), and a deterministic destination ('Experts/' vs 'Include/' chosen by extension). This clearly differentiates the core operation from build-only tools like compile and combined build-and-copy tools like compile_and_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?

The description explicitly points to compile_and_deploy as the alternative when building and copying are needed together, and the custom name parameter gives useful usage context. It does not discuss other sibling tools like deploy_ea or install_include, but the extension-based routing makes the intended usage fairly unambiguous.

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?

While annotations already label this as destructive (destructiveHint=true), the description adds crucial behavioral context: the tool is removed in version 0.6.0 and should not be invoked. This is a meaningful disclosure beyond what annotations provide, though it doesn't explain the tool's original behavior—acceptable for a deprecated stub.

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 fluff, and the deprecation warning is front-loaded. High signal-to-noise ratio.

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 deprecated tool, the description is complete: it tells the agent not to use it and where to go instead. No additional details are needed, and the presence of an output schema further reduces burden.

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 100%, so both parameters are already documented. The description adds no extra semantics about parameters, but the baseline 3 is appropriate as the schema carries the full meaning.

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

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

The description explicitly states that the tool is deprecated and directs the user to the successor `deploy(file, name)`, making the purpose and replacement unambiguous. It's not a tautology; it informs the agent that this tool is obsolete and not for use.

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

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

It gives explicit instruction on when to use this tool (never, since deprecated) and expressly names the alternative, `deploy`, satisfying the 'when-not' and 'alternative' guidance perfectly.

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?

Annotations already establish that the tool is read-only, idempotent, and non-destructive. The description adds some useful scope (paths, terminal hash, missing-component diagnosis) but does not explain behaviors like failure modes, output shape, or whether 'resolve' implies any workspace-side effect. The description does not contradict the annotations.

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 filler. It front-loads the core action ('Resolve and report') and immediately lists the relevant resource types, making it easy for an agent to parse quickly.

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

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

For a parameterless, read-only tool with an output schema and strong annotations, the description covers the essential purpose and scope. It is arguably complete enough to invoke correctly, though it would be more complete with a brief note about when to prefer it over sibling terminal-related tools.

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 declares zero parameters, so there is no parameter ambiguity for the agent to resolve. Per the baseline for parameterless tools, the description does not need to compensate for missing parameter documentation.

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

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

The description uses a specific verb-resource pairing: it 'resolves and reports' MT4/5 paths, terminal hashes, and missing-component issues. This clearly distinguishes it from sibling tools like list_terminals or select_terminal, and precisely identifies its focus.

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

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

The description gives no guidance on when to use this tool versus the many related sibling tools such as list_terminals, select_terminal, or list_backtests. There are no conditions, exclusions, or alternative routing hints, so the agent must infer usage 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?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds the crucial behavioral fact that the tool has been removed from the API and will not work, along with the migration path. This goes beyond the annotations and sets correct expectations without contradicting them.

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

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

The description is a single front-loaded sentence that immediately signals deprecation and then gives the replacement. There is no filler, and every word contributes to the agent's decision.

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 one-parameter, deprecated tool with rich annotations and an output schema, the description supplies the essential missing context: it is removed and should be replaced by inspect_source with aspects=['docs']. A small deduction is warranted because it does not explicitly say what calling it will do now or what the original return value was, but the deprecation warning largely covers this.

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

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

The only parameter, source, is already fully described in the schema as an absolute Windows path to .mq4/.mq5/.mqh files, so schema coverage is 100%. The description does not add additional parameter-level details beyond showing source used in the replacement call, which keeps this at the baseline.

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 does not directly state what extract_doc originally did, but it clearly marks the tool as removed and identifies the exact successor call, which conveys its doc-extraction purpose. It also distinguishes this tool from siblings by labeling it deprecated, though a direct 'extracts documentation' statement would make it fully explicit.

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

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

The description explicitly says the tool is deprecated/removed and gives the precise alternative invocation: inspect_source(source, aspects=["docs"]). This is exemplary usage guidance because it tells the agent not only to avoid this tool but exactly what to call 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?

The description discloses meaningful behavioral traits beyond the annotations: it uses brace-counting and regex rather than a full AST parser, returns a proposed helper/call site/parameter list, and requires explicitly setting dry_run=False to write. This adds real context beyond the destructiveHint annotation.

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

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

The description is compact and front-loaded: purpose first, then limitations, return content, and modification behavior. Every sentence contributes useful information without unnecessary verbosity.

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 key operational aspects: what the tool does, its algorithmic limitations, what it returns, and how to trigger a write. An output schema exists to explain return values. It could be slightly richer about failure modes or preconditions, but is largely complete for a destructive refactoring 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 100%, so all parameters are already documented clearly. The description adds minimal extra parameter semantics beyond restating the dry_run toggle, which the schema already explains. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Extract a contiguous block of lines into a new helper function.' This is clear and unambiguous. It does not explicitly differentiate from sibling tools like extract_doc or extract_inputs, though 'helper function' provides useful context.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. 'Set dry_run=False to write' explains how to apply changes, and 'not a full AST parser' hints at a limitation, but no alternative tool is named or contrasted.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds important lifecycle context: the tool is deprecated and removed in 0.6.0, which changes how an agent should treat it. It does not describe what happens if invoked, but the deprecation warning is sufficient for a removed tool.

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

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

The entire description is one sentence, front-loaded with 'DEPRECATED' and immediately followed by the exact replacement. Everything present is useful and nothing is wasted.

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 deprecated tool, the description provides the critical information an agent needs: stop using it and call inspect_source with the correct arguments. Combined with the full schema, safety annotations, and output schema, no important information is missing for correct decision-making.

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 covers the single 'source' parameter at 100%, so the baseline is 3. The description adds no additional meaning about the parameter's format or behavior, though it does show that 'source' carries over into the replacement call. This is adequate given the high schema coverage.

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

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

The description does not explicitly state what extract_inputs does; it only says it is deprecated and removed. The tool name and the replacement call ('aspects=["inputs"]') imply it extracted inputs from a source, but the purpose is inferred rather than stated. This is not a tautology, but it is not a full verb+resource definition either.

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

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

The description gives explicit, actionable guidance: do not use this tool; instead call inspect_source(source, aspects=['inputs']). This clearly differentiates it from the sibling and tells the agent exactly when an alternative should be selected.

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?

Annotations already communicate read-only, idempotent, and non-destructive behavior. The description adds the important lifecycle fact that the tool is removed in 0.6.0, which is useful context beyond the annotations, but it does not describe what happens if the tool is still invoked or what its original return behavior was.

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 entire description is one sentence, front-loaded with 'DEPRECATED' and immediately followed by the exact replacement call. There is no wasted text or redundant information.

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

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

For a deprecated tool, the most essential context is that it should not be used and what to use instead, both of which are present. The original tool's behavior is not described, but the output schema, annotations, and explicit redirect to inspect_source make the description sufficient for correct agent behavior.

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

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

The description provides no parameter details, but the input schema documents both 'root' and 'var_pattern' with 100% coverage. With the schema handling parameter semantics, a baseline score of 3 is appropriate.

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

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

The description does not directly state what find_magic_collision does, but the replacement call inspect_source(root=..., aspects=['magic']) and the tool name imply it was about magic-number collision detection. The purpose is discernible only indirectly, making it vague rather than explicit.

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

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

The description clearly says the tool is deprecated and removed, and gives the exact alternative invocation: inspect_source(root=..., aspects=['magic']). This is explicit do-not-use and use-this-instead guidance, which fully covers the when and why.

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 annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the critical behavioral fact that the tool is deprecated and removed in 0.6.0, which is beyond what annotations provide. It also hints that it is a search function via the replacement's parameters. No further behavioral context is needed for a deprecated tool.

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

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

The description is a single, front-loaded sentence that delivers the deprecation notice and the replacement route with no filler. Every character earns its place.

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

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

Given the tool is deprecated and has a clear replacement, the description is complete. An agent knows exactly what to do: avoid this tool and use inspect_source with the same parameters. No output schema explanation is necessary because the tool should not be invoked.

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 100% with clear descriptions for each parameter (e.g., 'Absolute path to the project folder', 'Identifier to search for'). The description adds no additional syntax or precedence guidance, but the baseline of 3 applies because the schema fully documents the 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 that the tool is deprecated and removed in 0.6.0, and explicitly names the replacement (inspect_source). While it doesn't restate the original purpose of find_symbol itself, for an agent this is the essential information to correctly select and invoke the tool. It also differentiates from inspect_source by design.

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

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

It provides explicit instructions on what to use instead: 'use inspect_source(root=..., symbol=...)'. This is a direct when-not-to-use and proper-alternative directive, leaving no ambiguity about how to handle this tool.

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

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

Annotations already disclose read-only, idempotent, and non-destructive behavior. The description adds critical behavioral context beyond those annotations: the tool is deprecated, removed in 0.6.0, and superseded by a tool that dry-runs by default. No contradiction exists.

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 front-loads the deprecation status and immediately provides an actionable replacement. Every word earns its place and the format is highly scannable.

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 deprecated tool, the description is complete: it states deprecation, removal version, replacement, and replacement behavior. Combined with the annotations and documented parameters, an agent has everything needed to avoid misuse.

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 100%, so parameters are already documented in the schema. The description adds no extra meaning about source or style, but none is required given the high schema coverage and the fact that the tool is deprecated.

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 never states what format_check actually does; it only announces deprecation and points to format_mql. The intended purpose must be inferred from the tool name, which is not sufficient for a clear definition.

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

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

The description explicitly tells the agent not to use this tool, names the exact replacement (format_mql), gives the invocation pattern (format_mql(source)), and notes the default dry-run behavior. This is ideal routing guidance for a deprecated tool.

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

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

Even though destructiveHint=true is already set, the description adds genuinely new behavioral context: the operation is a dry run by default, only becomes destructive when write=true, and protects MQL-specific constructs. This directly clarifies the destructive annotation rather than merely restating it.

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 short sentences deliver purpose, protection behavior, invocation mode, and legacy status without redundancy. The critical dry-run/write behavior is placed immediately after the purpose line, and every clause 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?

With an output schema present and 100% parameter coverage, the description covers everything needed to call the tool correctly: what it formats, what it protects, how the destructive flag works, and what it replaces. No critical caller-facing detail 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 100%, so a baseline of 3 applies; the description does add meaning by explaining that write=true applies changes and clarifying the default dry-run behavior. But it conflicts with the schema's write default of true and with the parameter description's claim that false is the default, which introduces ambiguity for an agent parsing both sources.

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

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

The description opens with a specific verb plus resource: 'Format an MQL file with clang-format' and adds the key distinguishing detail that MQL literals and `input group` lines are protected. It also states it replaces format_check, giving agents an explicit lineage and differentiating it from that sibling.

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 dry-run default and `write=true` switch are explicit instructions for how to invoke the tool safely, and 'Replaces format_check' gives a clear alternative/context signal. However, it does not spell out when to choose this over nearby lint/compile/syntax siblings or list exclusions, so it stops short of a 5.

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

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

Annotations already flag destructive behavior, and the description adds useful context by specifying that the block is 'appended/replaced in-place' when write_to points at a tester.ini. This clarifies exactly what gets modified without contradicting the annotations.

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 crisp sentences lead with the core purpose and immediately follow with the important side effect. There is no filler or redundant restatement.

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 output schema and annotations, the description provides the main invocation flow and side-effect warning. The only notable gap is that it does not explicitly say what happens when write_to is omitted, and the 'appended/replaced' wording could be more precise about overwrite semantics.

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 100%, so the baseline applies. The description adds some semantic color—'from EA inputs' and the in-place write behavior—but most parameter meaning is already captured by the property 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 states a specific action and resource: generating a `[TesterInputs]` block from EA inputs, and it clarifies the optional file-writing behavior. It distinguishes itself from closely named siblings like extract_inputs and patch_tester_ini through the explicit block target, though it does not name a sibling directly.

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 intended use is implied: use it to generate a `[TesterInputs]` block, optionally writing it to a tester.ini. However, there is no explicit guidance about when to prefer this tool over alternatives such as extract_inputs or patch_tester_ini, so an agent must infer selection 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?

Annotations already disclose readOnly, idempotent, and non-destructive behavior. The description adds value beyond those annotations by specifying the returned statuses, the inclusion of report path and journal notes once complete, and the newest-first ordering. No contradiction with annotations is present.

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

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

The entire description is a single compact sentence that front-loads the core purpose, packs the status values and result contents, and appends the run_id-less variant without filler. Every part 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 simple read-only query with fully documented parameters, annotations, and an output schema, the description is nearly complete. The main gap is that its 'without run_id, lists all runs' mode overlaps with the sibling list_backtests, and the description does not disambiguate when to use which tool.

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

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

The input schema has 100% description coverage for both parameters, so the baseline is 3. The description adds the 'newest first' ordering detail for the run_id-less case, but otherwise does not add meaning beyond the schema. tail_lines is not mentioned in the description, though the schema documents it 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 clearly identifies the resource ('background backtest') and the action (return status), and names the possible statuses: running, completed, timeout, cancelled. It also documents the list-all behavior when run_id is omitted, but it does not explicitly distinguish itself from the closely related sibling list_backtests.

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

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

The description gives a clear usage rule: omit run_id to list all runs newest first, which guides the agent for the optional-parameter case. It does not explicitly say when to prefer list_backtests or read_tester_report, but for the core status-checking scenario the guidance is sufficient.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior; the description reinforces this and adds useful behavioral detail such as '#include tree (with missing files)' and 'duplicate magic numbers', explaining what kind of facts are produced. It does not deeply describe edge-case behavior, but the output schema and annotations cover the rest.

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 efficient sentences with no filler. The primary capability is front-loaded, and the sibling replacement list is packed into a single closing line.

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 the schema has 100% parameter coverage Appendix and an output schema exists, the description only needs to orient the agent on what the tool is for and how it relates to alternatives. It does this completely, while the read-only annotations cover the safety model.

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 100% and all parameters have useful descriptions, so the baseline is 3. The description adds semantic nuance to the 'aspects' parameter by clarifying that includes means '#include tree (with missing files)', docs means 'MetaEditor doc blocks', and magic means 'duplicate magic numbers', which the schema's bare enum names do not fully convey.

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

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

The description states a specific scope ('Read-only facts about MQL source') and enumerates five concrete capabilities: input declarations, #include tree with missing files, MetaEditor doc blocks, symbol usages, and duplicate magic numbers. It also explicitly names the sibling tools it replaces, so an agent can distinguish it from extract_inputs, resolve_includes, extract_doc, find_symbol, and find_magic_collision.

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 'Replaces extract_inputs / resolve_includes / extract_doc / find_symbol / find_magic_collision' line is an explicit routing instruction: use this tool instead of those five siblings for those analysis needs. The 'Read-only' qualifier also marks the boundary against mutation 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?

Annotations already convey destructiveHint=true, so the safety profile is structured data. The description adds the important behavioral fact that the tool is deprecated/removed, but it does not disclose underlying side effects or failure behavior beyond that. This 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?

A single sentence that front-loads the critical DEPRECATED/removed status and immediately names the replacement. There is no wasted content.

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

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

For a deprecated/removed tool, the description tells the agent everything needed for the decision: avoid this tool and use deploy. It does not explain the original behavior, but that is secondary given the tool is removed and an alternative is named.

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 100%, so source and target_name are already fully documented. The description adds no parameter-level meaning, so the baseline of 3 applies.

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 does not state what install_include does; it only says it is deprecated, removed in 0.6.0, and suggests using deploy(file, name) with a .mqh file. The actual verb+resource behavior is left to inference from the tool name and schema.

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

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

The description explicitly instructs the agent to use an alternative: 'use deploy(file, name) with a .mqh file.' This is clear, unambiguous routing to the correct sibling tool and makes the deprecation actionable.

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?

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds meaningful behavioral context: the default scoping to server-started PIDs, the specific file names (terminal64.exe/terminal.exe), and the warning about live-trading terminals. This goes beyond the annotation's binary flag and helps the agent understand the exact blast radius.

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

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

The description is two concise sentences, front-loading the default behavior and then the destructive alternative. Every clause carries meaning: it explains the default scope, the safety guarantee, and the explicit destructive flag. No redundancy or filler.

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

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

For a tool with a single optional parameter and a clear output schema, the description fully covers the behavior, the parameter semantics, and the safety profile. It tells the agent exactly when to use the default and when to escalate, and it addresses the risk of collateral damage. Nothing critical is missing for correct invocation.

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

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

The schema already covers all_instances with a 100% description coverage, giving the baseline of 3. The description adds a small but useful detail: it specifies 'terminal64.exe/terminal.exe' for the all_instances case, which clarifies the exact processes affected. This is a slight enhancement over the schema's wording, justifying a 4.

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

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

The description opens with a specific verb ('Force-kill') and a clear resource ('terminal processes launched by this server'), and explicitly ties it to run_backtest / smoke_test. It also distinguishes this tool from the sibling select_terminal and list_terminals by stating what it does not touch (live-trading terminals).

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

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

The description gives explicit when-to-use context: by default it only kills server-launched PIDs, and it warns that passing all_instances=True is destructive and may affect a live-trading terminal. It effectively says when not to use the destructive option and clarifies the safe default, leaving no ambiguity about which invocation to choose.

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?

Annotations already show readOnly/idempotent/non-destructive behavior. The description adds critical deprecation status and the exact replacement call, providing more context than the annotations alone. No contradiction exists.

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?

One sentence front-loaded with DEPRECATED, immediately followed by the replacement. Every word earns its place with zero waste.

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

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

For a deprecated tool, the guidance is complete: the agent is told not to use it and exactly what to call instead. Slightly less than 5 because the description does not define the original behavior, but given the deprecation this is sufficient.

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

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

Schema coverage is 100% and the only parameter, source, is fully described as an absolute Windows path. The description adds no parameter detail, but none is needed because the schema is sufficient. Baseline 3 applies.

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 is primarily a deprecation notice rather than a definition. It never directly states that the tool lints a source file, though the name and the call to analyze_mql(source, checks=["lint"]) make the purpose inferable. This is clear for a deprecated tool, but it doesn't explicitly say what the tool does.

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

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

Explicitly instructs to use analyze_mql(source, checks=['lint']) instead, making the correct alternative and invocation unambiguous. It also notes the timeline (removed in 0.6.0), so an agent knows not to rely on this tool.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds the critical lifecycle fact that the tool was removed in 0.6.0, which goes beyond what annotations state. It does not spell out the exact failure mode, but 'removed' strongly implies the tool should not be called.

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 one short sentence that front-loads the most important signal, 'DEPRECATED', and then gives the replacement action. 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 deprecated tool with no parameters and an output schema provided, the description contains all an agent needs to make the correct decision: do not call this, call get_backtest() instead.

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

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

There are zero parameters and schema coverage is 100%, so the schema already fully documents the input surface. The description correctly focuses on deprecation instead of repeating parameter information.

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

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

The description does not explain the original list_backtests behavior, but it clearly communicates that the tool is deprecated and points to get_backtest() as the replacement. This is enough for an agent to recognize that it should not be invoked and to choose the correct sibling.

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

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

It explicitly tells the agent not to use this tool and names the exact alternative and invocation style: 'use get_backtest() without run_id.' This is unambiguous routing guidance for a deprecated tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by naming the directory and the platform-dependent default glob, but it does not go beyond that. With annotations doing most of the safety disclosure, a 3 is appropriate.

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, well-structured sentence that leads with the core action and resource, then adds the platform-specific detail. There is no filler, and every part of the 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?

For a low-complexity read-only listing tool, the description plus the fully documented schema and the provided output schema are sufficient. The directory, defaults, and parameters are all covered, so nothing critical is missing for an agent to call this 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 100%, and the input schema already documents both 'pattern' and 'recurse' clearly, including the default glob behavior. The description repeats the platform-specific default rather than adding new parameter meaning, so the baseline of 3 applies.

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

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

The description uses a specific verb ('List'), names the exact resource ('compiled EAs in Experts/'), and clarifies the platform-specific default patterns (*.ex5 for MT5, *.ex4 for MT4). This clearly distinguishes it from sibling list tools like list_snapshots, list_terminals, and list_backtests.

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 establishes a clear context: it is for listing compiled EAs in the Experts/ directory, with platform-aware defaults. It does not explicitly name alternatives or state when not to use it, but the scoping is strong enough that an agent can infer the right use case without confusion.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety and side-effect profile. The description adds no extra behavioral context (e.g., return format, pagination, permissions), but does not contradict annotations. With annotations present, this is an adequate baseline.

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 zero filler. It states exactly what the tool does and the required location parameter. 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 simple, one-parameter read-only listing operation with annotations covering safety and an output schema present, the description is fully sufficient. No additional information is needed for an agent to call this tool correctly.

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

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

Schema description coverage is 100%: the parameter 'dest' is described as 'Absolute path to the folder that holds snapshots.' The tool description merely references dest without adding additional meaning, so it does not enhance beyond the schema. Baseline of 3 applies.

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

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

The description 'List all snapshot folders under dest' clearly states a specific action (list) and resource (snapshot folders) with a location constraint. It is unambiguous and distinguishes itself from the sibling snapshot_sources (which likely creates snapshots) by its focus on 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 when to use it (when you need to enumerate existing snapshot folders), but does not explicitly mention alternatives or exclusions. The context is clear and the action is self-evident, so it meets the 'clear context, no exclusions' threshold.

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 aligns with annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) and adds no contradictory behavior. It does not go beyond the annotations by describing output shape, environment requirements, or potential quirks, but for a simple enumeration tool the annotation coverage lessens the burden on the description.

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 filler. It communicates the operation, the resource, and the exact location in as few words as possible.

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 zero parameters and an output schema present, the description covers everything needed to invoke the tool correctly. It states the exact directory and the operation performed, leaving no ambiguity 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?

The tool has zero parameters, so the description cannot add parameter-level meaning. Per the baseline for 0-parameter tools, a score of 4 is appropriate; no further parameter explanation 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 ('Enumerate') and a specific resource ('MetaTrader terminal data folders under %APPDATA%\MetaQuotes\Terminal'). It clearly distinguishes this from sibling tools like list_snapshots or list_backtests without needing to inspect schemas.

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 makes the tool's use-case obvious: call it when you need to list all terminal data folders. However, it does not explicitly mention alternatives or exclusion criteria, such as when to prefer select_terminal or list_snapshots. Usage guidance is implied rather than stated.

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

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

Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already declare the tool as a safe, non-destructive read. The description adds only the deprecation status heavily implying it is non-functional. It does not disclose any behavioral traits beyond 'removed', which is critical but still leaves ambiguity about what happens when called (likely error). No contradiction with annotations.

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, extremely concise, but it is under-specified. It front-loads the deprecation warning and the alternative, which is useful, but it omission of any purpose or usage details makes it inadequate despite brevity.

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 the tool is deprecated and removed, the description should clearly state that it is non-functional and must not be used, and point to the alternative. It does that, but it lacks any information about what the tool actually did (parse optimization data) which is necessary for an agent to understand the alternative's relevance. The output schema exists but the description doesn't need to explain return values; still, the overall context for a deprecated tool is insufficient.

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 100%, so the schema documents all five parameters. The description provides no additional semantic meaning for parameters; it only names an alternative function. The parameter descriptions in schema are sufficient but generic (e.g., 'path', 'expert'), and the description does not compensate for any nuance, leaving a gap for a deprecated tool.

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

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

The description is 'DEPRECATED (removed in 0.6.0): use read_optimization(...).' It does not state what the tool does, only that it is deprecated and points to an alternative. The name 'parse_optimization' suggests parsing optimization data, but the description is a tautology of the deprecation status, not the purpose.

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

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

The description explicitly tells the agent to use read_optimization instead, which is a clear when-not-to-use directive. However, it provides no guidance on when the tool itself might be used (which is never, since it's removed), and no context about the alternative's usage. Thus, it is misleading for actual 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?

Beyond destructiveHint=true, the description discloses that it preserves the file's encoding and other lines, adds missing sections/keys, and modifies in place. This tells the agent what side effects to expect and what is preserved, which is exactly the contextual value annotations don't carry.

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 first sentence is a clear, informative one-liner; the second block gives concrete examples and critical usage caveats with no filler. 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?

For a mutating config tool, the description covers what is preserved, how updates are applied, required follow-up validation, and mandatory keys to avoid stale UI state. Combined with the output schema and annotations, nothing essential is missing for correct invocation.

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

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

Both params are already described in schema (100% coverage), and the description adds behavior for the updates object: missing sections/keys are added, with a concrete mapping example. It reinforces the dotted Section.Key format and lists critical keys that should be set, going beyond schema basics.

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

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

The description states a specific action and target ('Set keys in a tester.ini in place'), with 'in place' clarifying mutation scope. It is clearly distinct from sibling tools like validate_tester_ini, which checks the file, and run_backtest, which consumes it.

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

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

It gives practical invocation guidance: run validate_tester_ini afterwards and always set a named list of keys so a run does not inherit UI state. It doesn't express when-not-to-use or name an alternative, but the guidance is explicit enough for correct 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's safe. The description adds that all passes are used for ranking ('Ranking uses every pass'), which is useful context beyond the annotations, clarifying the internal behavior.

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

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

The description is two sentences long and front-loads the core purpose before the caveat. Every sentence earns its place: the first states what it reads and returns, the second adds behavioral guidance and names siblings. 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?

Given that an output schema exists)Skip, the description need not explain return values. It covers key aspects: what the tool does, its scope, how to select it over siblings, and a critical usage caveat. With 7 parameters but 0 required compartments, the simple and complete description is sufficient for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add parameter-specific semantics beyond what is in the schema, but it does hint at the purpose of parameter selection via 'top N passes by criterion', aligning with top_n and criterion. No additional info 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 states a specific verb (read) and resource (MT5 optimisation cache .opt), and lists the key outputs (header, optimised inputs, pass count, top N passes). It also names two sibling tools (parse_optimization, top_passes) that it replaces, clearly distinguishing its scope.

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

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

The description explicitly says it replaces parse_optimization and top_passes, signaling when to choose this tool over those alternatives. It also provides a usage caveat: 'The best pass of a genetic run is a biased sample; prefer robust neighbourhoods' – guiding the agent on how to interpret results and when to be cautious.

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?

Annotations already declare readOnlyHint and idempotentHint, so the description adds valuable behavior beyond them: the risky default of using the newest report without `path`, the fact that `summary` values are raw strings rather than numbers, and the distinction between this tool and reading the `mt5://report/{id}` resource directly.

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 tightly packed sentences convey purpose, usage guidance, and caveats with zero fluff. The core function is front-loaded, followed by actionable alternatives and a warning about output types.

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 sufficiently covers purpose, path selection, output semantics, and alternative tools. Combined with the input schema (100% parameter coverage) and an output schema, an agent has everything needed to select and invoke this tool correctly.

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

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

Schema description coverage is 100% for all four parameters, so the baseline is 3. The description adds useful context for `path` (prefer backtest-returned path; fallback can be stale) and for `raw_truncate` (read `report_uri` instead for full HTML), which elevates it above the baseline.

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

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

The description opens with a specific verb and resource: 'Parse a Strategy Tester HTML report (MT5 or MT4) into `summary` metrics'. It also states what it does not do (the full HTML stays behind `report_uri`), which distinguishes it from sibling tools like `read_optimization` or `compare_reports`.

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?

Explicit guidance is given on when to use this tool: 'Prefer passing the `report_path` returned by `run_backtest`/`get_backtest`'. It also names alternatives for related tasks ('use `compare_reports` / `regression_check` for numeric comparison') and warns against the default fallback behavior ('newest report on disk... may belong to an older run').

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

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

It states the tool is deprecated and removed, a critical behavioral fact not captured by the annotations (readOnlyHint, idempotentHint). This goes beyond structured metadata and tells the agent the tool is non-operational, preventing any attempt to invoke it.

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 entire description is a single, front-loaded sentence with 'DEPRECATED' at the very start, immediately signaling the key message. Every word is essential, and the instruction to use the replacement is clear and succinct.

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 deprecated tool, this is complete. It tells the agent whether to use it (no) and exactly what to use instead, including the call signature. No additional information about return values or behavior is needed because the tool is non-functional.

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 covers 100% of parameter descriptions, so the baseline for this dimension is 3. The description adds no further semantics about the tool's own parameters; it only references parameters in the alternative tool. This is acceptable for a deprecated tool, but no extra value is provided.

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 is DEPRECATED and removed in 0.6.0, which tells an agent it should not be used. It also points to the specific replacement tool, compare_reports, distinguishing it from siblings. While it does not explain the original function, that is unnecessary given the deprecation 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 directly instructs the agent to use compare_reports(baseline, candidate, guards=...), providing the exact alternative and required parameters. This is an explicit, unambiguous usage directive with no room for misinterpretation.

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?

For a tool already marked destructiveHint=true, the description adds a valuable safety detail: dry_run=True previews only. It also clarifies the scope of edits via 'across MQL files' and 'whole-word match'. It does not detail irreversibility, but the annotation already signals destructive behavior and nothing here contradicts it.

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 the core action and the key safety caveat front-loaded. No filler, and every clause earns its place.

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

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

Given the rich input schema, an output schema, and destructive annotations, the description is largely sufficient for a correct call. It could still state explicitly that dry_run=false persists changes to disk, though that is fully documented under the dry_run parameter.

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 100%, so the baseline is 3. The description mostly restates the whole-word constraint and dry_run preview behavior already present in the parameter descriptions. It adds little semantic value beyond what the schema provides.

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

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

The description names a specific verb ('Rename'), a specific resource ('a symbol across MQL files'), and a matching constraint ('whole-word match'). This clearly distinguishes it from sibling discovery or formatting tools like find_symbol or format_mql.

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 intended use is implied by 'Rename a symbol across MQL files', and the dry_run note suggests a safe preview workflow. However, it gives no explicit when-to-use versus alternatives, no prerequisites, and no exclusions or conditions for when the destructive path should be chosen.

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 annotations already provide readOnlyHint=true entertaining, idempotentHint=true, and destructiveHint=false, which are consistent with the description's deprecation status. The description adds that the tool is deprecated and removed in 0.6.0, which is critical behavioral context beyond the annotations. There is no contradiction, and the deprecation disclosure is transparent.

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

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

The description is a single sentence with zero waste. It immediately front-loads the DEPRECATED flag and the replacement instruction, making it highly efficient for an agent scanning options. Perfect minimalism for a deprecation notice.

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 deprecated tool, the description is complete in guiding an agent away from it, and the output schema exists for return type context. However, it doesn't explain what the tool originally returned or its historical behavior, which could be relevant if an agent encounters old references. Given the strong deprecation guidance, a 3 is fair.

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 schema description coverage at 100%, the schema already documents both parameters (source and mql_root). The description adds no new meaning about these parameters, but the baseline for high coverage is 3. The description's deprecation notice implies the parameters are irrelevant, but that doesn't enhance semantics.

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 is a deprecation notice rather than a statement of what the tool does. It says it is deprecated and directs users to use inspect_source instead, but does not mention what resolve_includes actually does (e.g., resolving include dependencies in MQL source files). The verb is missing; the purpose is only implicit.

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

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

The description explicitly tells users not to use this tool and to use inspect_source with aspects=['includes'] instead, which is a strong usage exclusion. However, it does not explain when this tool was used or under what conditions an agent might still encounter it, such as backward compatibility or migration 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?

Annotations provide no behavioral hints (all false), so the description carries the full burden. It discloses expected duration (1-30 minutes), progress notifications, automatic retry on history sync error, output fields, and the `start_time_changed` warning. This goes well beyond minimal requirements and gives the agent a realistic model of side effects and failure modes.

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

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

Every sentence earns its place: purpose, prerequisites, timing, retry logic, alternative, and return value caveats. Instructions are front-loaded and the structure is logical, with 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?

For a complex tool with prerequisites, retries, and specific return semantics, the description is thorough. It covers deployment requirements, blocking behavior, timeout, return fields, and the warning about report comparability. The output schema exists, so return details need not be repeated. Nothing critical is missing for correct invocation.

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

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

Schema coverage is 100% so parameters are already well-documented. The description adds value by clarifying the interaction between `wait` and `ShutdownTerminal=1`, the timeout fallback, and the resolution of `report_path` from the ini. This exceeds the baseline of 3 for fully covered schemas, but is not essential enough to reach 5.

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

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

The description opens with a precise verb+resource: 'Run a Strategy Tester backtest headlessly from a tester.ini and wait for it to finish.' It clearly distinguishes itself from siblings like `start_backtest` and `get_backtest` by emphasizing the blocking behavior and explicitly naming the alternative for long runs.

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

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

Explicitly states prerequisites (EA must be deployed, `ShutdownTerminal=1` required) and gives a conditional behavior (otherwise runs until `timeout_sec`). It also provides an alternative: 'For long runs prefer `start_backtest` + `get_backtest`', which is a clear when-not-to-use instruction.

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?

Beyond the annotations, the description discloses the lasting side effect ('Subsequent tool calls will use the new layout until the server restarts'), which is valuable because annotations only report false hints. It does not over-promise persistence or claim destructive behavior.

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

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

The description is short, front-loaded with the core action, and every sentence contributes either a mode definition or a behavioral consequence. There is no redundant phrasing or filler.

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

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

For a simple session-switching tool, the description covers the selection modes and the session-scoped lifecycle. It leaves minor ambiguity about what happens if no mode or multiple modes are supplied, but the schema and output schema cover the remaining details.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description adds the useful notion that these are mutually exclusive selection modes, but it does not mention the edition parameter and adds only modest semantic 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 first sentence states a specific action ('Switch'), resource ('active terminal data folder'), and scope ('for this session'). This clearly differentiates it from sibling tools like list_terminals or kill_terminal, and the name does not need to be restated.

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

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

The description explicitly instructs the agent to provide one of origin, hash, or install and explains what each option means. It gives clear selection context for the parameter modes, though it does not explicitly compare this tool to sibling alternatives such as list_terminals for discovering folder hashes.

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 important behavioral traits beyond the annotations: it overwrites an existing EA of the same name in Experts/, takes 1-10 minutes, and reports both `ok` and `stage` so the caller knows where execution stopped. This complements the destructiveHint=true annotation with concrete details and does not contradict it.

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

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

Three sentences carry substantial value: the first captures the core action and stages, the second explains the failure modes it detects and the result semantics, and the third discloses side effects and duration. There is no filler or repetition of schema fields.

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 rich input schema, an output schema, and annotations that mark the tool destructive, the description adds the missing context: the overwrite side effect, expected runtime, and the stage/ok behavior. Nothing an agent needs to invoke or interpret this tool correctly is left unaddressed.

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 100%, so every parameter already carries a meaningful description. The tool description adds only high-level context like '1-day headless backtest,' which aligns with the `days` default but does not materially extend per-parameter semantics. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('One-call health check for an EA') and enumerates the four stages it performs: compile, deploy, run a 1-day headless backtest, and scan the journal. This clearly distinguishes it from sibling tools like compile or run_backtest, which perform only individual stages.

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

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

The description gives clear context for when to use the tool: it catches problems that compile cleanly but fail at runtime, such as OnInit errors, array out of range, and divide by zero. It does not explicitly name alternatives or state when not to use it, but the 'one-call' framing implies it replaces the multi-step sequence without needing further 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?

Annotations already declare idempotentHint=true and destructiveHint=false, and the description does not contradict them. It adds the detail that the copy is placed in a timestamped folder under dest, which is useful context. However, it does not elaborate on what happens to the original files, whether the dest directory needs to exist, or any side effects beyond the copy.

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 filler words. It front-loads the core action ('freeze a copy of source files') and specifies the destination location concisely. Every word contributes meaning.

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

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

The tool is relatively simple, and the description covers the essential action. An output schema exists, so return values are presumably documented there. The description is sufficient for an agent to understand the tool's purpose, though it leaves minor questions like dest directory existence or label behavior to the schema, which is already thorough.

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 description coverage is 100%, with all three parameters (sources, dest, label) having descriptive texts. The description adds no extra parameter semantics beyond the schema, so a baseline score of 3 is appropriate given high schema coverage.

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

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

The description uses a specific verb ('Freeze a copy of source files') and explicit resources, making it clear the tool creates a snapshot under a destination folder. It does not name an alternative sibling, but the verb 'snapshot' and the resource 'source files' clearly distinguish it from siblings like list_snapshots or compile, so purpose is clear.

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 you want to freeze a copy of source files into a timestamped folder. However, it does not explicitly state when NOT to use this tool or mention alternative tools like list_snapshots or compile. The context is implied but not made explicit.

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

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

Annotations are all negative flags, so the description carries the behavioral burden. It usefully discloses asynchronous execution, immediate return with a run_id, persistence to .mt5tmp/runs/<run_id>.json, and the concurrency constraint. It does not detail terminal cleanup or lifecycle beyond what the timeout_sec parameter already conveys, but the key behavior is transparent.

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

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

Three sentences with no wasted words. The first sentence front-loads the core purpose, and the following sentences each add essential operational detail: polling, result fields, persistence, and concurrency. 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?

For a background-launch tool with 100% schema coverage and an output schema, the description is complete. It tells the agent what happens immediately, how to retrieve the result, where artifacts land, and the concurrency limitation that can affect invocation.

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

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

Schema description coverage is 100%, and the description adds no parameter-specific meaning beyond the schema. The baseline of 3 applies because the schema already documents config, portable, and timeout_sec 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 clearly states a specific verb and resource: 'Launch a backtest in the background and return immediately with a run_id.' This distinguishes it from synchronous alternatives like run_backtest and clarifies what the tool produces. The follow-up reference to get_backtest further reinforces its role in the workflow.

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

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

The description gives clear operational guidance: poll get_backtest until status changes, read the final report_path and journal_notes, and be aware that only one terminal per install can test at a time. It does not explicitly contrast with sibling tools such as run_backtest, but the background-async context makes the intended use evident.

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?

Annotations are all false, so the description carries the burden. It discloses the deprecation and removal version, which is critical behavioral context, but does not state what happens if called (e.g., error, no-op). A warning about deprecation is transparent, but incomplete regarding actual runtime behavior.

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

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

One dense sentence that front-loads the deprecation and provides the exact alternative. Zero wasted words.

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

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

For a deprecated tool, the most important context is the replacement, which is clearly provided. The output schema exists, so return values are not the focus; the description fully informs an agent of its status and the correct action.

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 100%, so the schema already documents both parameters. The description adds nothing about parameters, which is acceptable given the high schema coverage; baseline 3 is appropriate.

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 name and description together make it clear this checks syntax, and the description explicitly states it is deprecated and directs to compile(source, syntax_only=true) as a replacement. It distinguishes from siblings by naming the substitute, though it doesn't explicitly restate the verb+resource.

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

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

The description gives explicit guidance: never use this tool, and exactly what to use instead (compile with syntax_only=true). This is the clearest possible direction for an agent.

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

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

Annotations already mark the tool as read-only, idempotent, and non-destructive, lowering the burden on the description. The description adds valuable behavioral context by identifying the exact log paths/sources and noting that tester mode reveals the effective test period. No contradiction with annotations.

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

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

The description is two short sentences with no filler. The core purpose is front-loaded, and the tester-mode hint adds practical value without bloating the definition.

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 zero required parameters, an existing output schema, and annotations covering safety, the description covers the main use cases well. It omits the 'terminal' mode in the prose, but the schema already documents that mode, so the gap is minor.

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 100%, so the schema already documents all four parameters in detail. The description reinforces the tester mode usage but does not add meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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 ('Tail') with a clear resource ('a MetaTrader log') and enumerates the three distinct sources (EA LiveLog.txt, daily Experts journal, latest tester journal). This maps cleanly to the mode enum and separates the tool from unrelated 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?

The description explicitly advises using mode='tester' right after a backtest to see runtime errors and the effective test period, which is a concrete usage guideline. It doesn't name alternative tools or say when not to use tail_log, but the provided context is clear and actionable.

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?

Adds the critical behavioral fact of deprecation and removal in 0.6.0, which annotations do not cover. The read-only and idempotent hints are already provided by annotations, so the description adds valuable context about the tool's status.

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

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

A single, front-loaded sentence that immediately flags deprecation and gives the replacement call. Zero waste and highly scannable.

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 deprecated tool, the description fully serves its purpose by directing the agent away. The output schema and annotations cover the rest, and no additional detail about return values or behavior is necessary.

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 descriptions cover all 7 parameters with clear meanings. The tool description adds no parameter-specific guidance, but the deprecation notice implicitly tells the agent not to worry about parameters. Baseline 3 applies given 100% schema coverage.

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

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

The description clearly states the tool is deprecated and directs the agent to a replacement, which is a specific purpose for a deprecated tool. It distinguishes itself from siblings by naming the successor, though it does not describe the original functionality beyond the name and parameters.

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 instructs the agent to use read_optimization(criterion=..., top_n=...) instead, leaving no ambiguity about when or whether to use this tool. This is ideal 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?

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the conditional behavior that providing `source` triggers a cross-check of [TesterInputs] against EA declarations, which is useful context beyond the annotations. It does not contradict annotations and enriches the agent's model of what happens during invocation.

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

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

The description is two sentences with no wasted words. The primary action is front-loaded, and the conditional behavior is stated compactly in the second sentence. Every phrase adds information, and there is no redundancy with the schema beyond the necessary repetition of the conditional behavior.

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

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

For a simple two-parameter tool with an output schema and comprehensive annotations, the description is adequate. It states the main purpose and the optional cross-check behavior, while the schema handles parameter details and the output schema covers return values. It could be more explicit about when in a workflow this should be used, but nothing critical is missing for a correct invocation.

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

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

Schema description coverage is 100%, so the schema fully documents both `config` and `source`. The description essentially repeats the schema's explanation for `source` ('cross-check inputs vs EA declarations') without adding new syntax, format, or edge-case details. It does not mislead, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb-resource pair ('Sanity-check a tester.ini') and adds a conditional cross-check behavior against EA declarations. This clearly differentiates it from sibling tools like patch_tester_ini (modification), gen_tester_inputs (generation), and read_tester_report (reading results), so an agent can select it without opening the schema.

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: you use it when you need to sanity-check a tester.ini, and the conditional 'If `source` given' gives one usage variant. However, it does not state when to prefer this over alternatives, nor does it mention prerequisite conditions like running before a backtest. There is no explicit when/when-not guidance, only an implied one.

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