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 nothing beyond that: it does not say what the analysis considers (orientation, support angle, nozzle size), what the result means, or that the operation is a pure calculation with no side effects.

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

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

It is a single short sentence with no waste, but this is under-specification rather than conciseness: the one sentence is not front-loaded with actionable information and omits everything an agent needs beyond the headline check.

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 3-parameter tool with no output schema, no enums, no required parameters and zero schema coverage, the description should at minimum name the printer options, describe nozzle/support-angle effects, and indicate the boolean/threshold nature of the answer. None of that is present.

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

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

Schema description coverage is 0% and the description mentions none of the three parameters. printer (a printer selector with a default of bambu_a1_mini), nozzle_mm and support_angle_deg are completely undocumented in both schema text and description, leaving the agent to guess valid printer values and unit conventions.

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 conveys the check being performed (does the part fit the Bambu A1 / A1 mini build volume), but it is phrased as a question rather than a verb+resource statement, and it never uses the tool's own verb 'analyze'. No sibling tool performs a comparable check, so differentiation is not a problem, but the purpose is stated loosely.

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?

There is no when-to-use guidance, no prerequisites (e.g. a design must exist first), and no mention of alternatives such as measure or validate. The implied context is 'after creating a design, before exporting', but the agent must infer all of it.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent knows this is a non-idempotent mutation that is not destructive. The description adds only a vague note about models/ resolution and says nothing about whether the part is persisted to the active design, what happens on repeat calls, or what errors occur on a bad source path.

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

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

It is a single short sentence with no padding, which is structurally efficient and front-loaded. However, brevity here reflects under-specification rather than tight editing, so it cannot score higher.

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 5-parameter mutation tool with 0% schema description coverage, no output schema, and only three bare annotations, the description is far too thin. An agent could not reliably call this tool from the definition alone.

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

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

Schema description coverage is 0% across 5 parameters, so the description must carry the burden and it does not. It gestures at 'source' pulling a model from models/ but gives no syntax, and says nothing at all about name, role, placement_mm, or rotation_deg (units, expected tuple shape, defaults).

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

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

The description is a sentence fragment with no verb: 'Assembly component and, if source is given, a model from models/.' An agent can infer this is about adding a part to an assembly, but the tool's actual action (add/create/link) and its effect on the design are never stated. It does not distinguish itself from siblings such as joint_create or import_cad_file.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives among the many siblings (joint_create, import_cad_file, inspect_part). The only conditional hint ('if source is given') describes a parameter, not a usage 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 declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that — no note on cost, whether it requires both designs loaded, or what the comparison yields.

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 short sentence that is under-specified rather than concise — it omits the object of comparison and any usage context, so brevity comes at the cost of clarity.

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

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

With 3 parameters at 0% schema coverage, no output schema, and only a terse one-liner, an agent lacks enough information to know what `a` and `b` should contain or how to interpret results. Annotations cover safety but nothing else.

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

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

Schema description coverage is 0%, so the description carries the burden but only partially compensates: it effectively enumerates the `kind` values (shape, fit, align, snapshot), which the schema leaves as a bare string with default 'shape'. The required `a` and optional `b` parameters remain entirely unexplained.

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

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

States a verb ('Сравнение'/compare) and enumerates the comparison modes (shape, fit, align, snapshot), so the domain is discernible. However it never says what is being compared (parts? revisions? a vs b?), leaving the core subject ambiguous and not differentiated from siblings like measure or interference.

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

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

No indication of when to use this tool versus measure, validate, interference, or other analysis siblings. The list of modes hints at scope but provides no selection criteria or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that: no indication of cost, required preconditions (design loaded? units?), or return format.

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?

It is a single short, front-loaded clause with no filler, which is structurally clean. But brevity here is under-specification rather than genuine conciseness — the sentence carries no actionable detail.

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

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

No output schema, zero parameter documentation, and no usage context. For a numerical geometry tool whose result interpretation (units, slice count effect) matters, the definition leaves the agent unable to call it correctly or interpret what comes back.

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

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

Schema description coverage is 0% for both parameters. The description alludes to an axis but gives no format, allowed values, or default, and says nothing about 'num_slices' — the slicing resolution that determines result fidelity. With two fully undocumented parameters, the description fails to compensate.

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

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

The phrase 'Площади сечений вдоль оси' (cross-sectional areas along an axis) names the computed quantity and the axis dependency, so the resource is identifiable. However it is a bare noun phrase with no verb and no differentiation from siblings such as 'measure' or 'inspect_part', which plausibly also return geometric quantities.

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?

There is no guidance whatsoever on when to call this tool, what conditions must hold (e.g. a loaded model must exist), or which sibling to prefer for related measurements. The agent must guess entirely from the name.

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 state readOnlyHint=false, idempotentHint=false, destructiveHint=false, and the phrase 'reverts' is loosely consistent with the non-destructive hint. However, with no output schema and no explanation of what the perturbation measures, whether state is fully restored on failure, or what the results look like, the behavioral picture is largely opaque. It neither contradicts nor meaningfully enriches 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?

It is a single short sentence with no waste, but brevity here is under-specification rather than conciseness — nothing is front-loaded because there is essentially no content to structure.

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

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

For a two-parameter tool with 0% schema description coverage, no output schema, and no annotations compensating for result behavior, the description is far too thin. It omits what is perturbed, how results are reported, and how the rollback behaves, leaving the agent unable to use the tool correctly.

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

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

Schema description coverage is 0% for both parameters. The description references '±ε', giving a faint gloss on the epsilon parameter, but says nothing about max_params (the cap on how many parameters are perturbed) or default/range semantics. With low coverage the description should compensate but does not.

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 ('Шевелит параметры на ±ε и откатывает') describes a mechanical action — perturbing parameters by ±ε and reverting — but never states that this is a design audit, a sensitivity/sensitivity-analysis operation, or what the tool actually produces. An agent cannot distinguish it from a generic param-jiggle helper among siblings like params_set or measure 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?

There is no indication of when to use this tool versus siblings such as params_set, validate, or measure. No prerequisites, no exclusions, no alternative routing are provided. The agent must guess the use case entirely.

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 say readOnlyHint=false, idempotentHint=false, destructiveHint=false, so this may mutate its sandbox but is not destructive. The description adds nothing beyond that: no statement about execution sandbox limits, the 120s default timeout, side effects on the Fusion document, or what a run returns. For an arbitrary-code-execution tool with only partial annotation coverage, that is a real gap.

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

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

Two very short sentences, front-loaded with the essential fact (Python sandbox) and then the available helpers. No padding, though the brevity is partly under-specification rather than discipline.

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 an arbitrary code execution tool with no output schema, no annotation detail on persistence or auth, and 0% parameter documentation, the description is too thin. An agent cannot tell scope of effects, timeout behavior, or how helpers are exposed.

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

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

Schema description coverage is 0%, so the description must carry the burden for 'code' and 'timeout_s', yet it explains neither. The helper names (make_box_mm, mm, show, measure) hint at the code environment but do not document 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?

States that it runs Python in a Fusion sandbox, which is a concrete verb+resource, but it never distinguishes itself from the sibling tools 'script' and 'execute_file', which plausibly do overlapping things. The helper list adds flavor but not differentiation.

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

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

There is no guidance on when to use this versus 'script' or 'execute_file', no prerequisites, and no conditions or exclusions. The agent must infer usage purely from the name.

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 declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the write/idempotency profile is already covered. The description adds genuinely useful behavior beyond that: an automatic snapshot rollback when the build fails. It still omits whether code is executed in a sandbox, what permissions are needed, and whether partial output survives a rollback.

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

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

Two short sentences with the action front-loaded and no filler. The terseness is efficient but tips into under-specification for a four-parameter tool, so it is neither wasteful nor fully earning its length.

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 non-read-only, non-idempotent execution tool with four undocumented parameters and no output schema, the description says far too little. The rollback note is the one substantive detail; execution scope, error surface, and parameter meanings are all missing.

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

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

Schema description coverage is 0% across four parameters, so the description carries the full burden and does not meet it. The word 'снимок' (snapshot) hints at the snapshot parameter but never explains what path, params_json, or result_name do. An agent cannot populate the optional parameters from this text.

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 verb (build/assemble) and a resource (models/*.py), which is more than a restatement of the name. However, it is not clear how this differs from the sibling 'execute' or 'script', and the target 'models/*.py' is ambiguous for a tool named execute_file. An agent must guess whether this runs arbitrary files or a specific build step.

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?

There is no guidance on when to use this tool versus the closely related 'execute', 'script', or 'workflow_hints' siblings. The only situational cue is implicit ('on error'), and no prerequisites or alternatives are named.

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 state readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds only a vague hint that a verification file is produced and a copy lands in exports/, without explaining overwrite/force behavior or what the verification step entails.

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?

It is short, but brevity here is under-specification rather than conciseness: the two fragments are cryptic and not front-loaded with the tool's action. No useful information is conveyed in proportion to its length.

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 0% schema description coverage, no output schema, and only minimal safety annotations, the description carries nearly the full explanatory burden and fails it. An agent lacks enough information to invoke the tool correctly or understand its side effects.

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

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

Schema description coverage is 0% for four parameters (force, formats, filename, object_name), and the description explains none of them. Filename is required and force/formats are consequential, yet the text adds no meaning beyond the bare property names, so the schema gap is left entirely unfilled.

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 reads as fragments ('Проверочный файл, затем копия в exports/. STEP — мастер.') rather than a statement of what the tool does. It hints at a file check followed by a copy into exports/ and something about STEP, but never says what is being exported or from where, so an agent cannot distinguish it from siblings like import_cad_file or script.

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?

There is no when-to-use guidance, no conditions, and no mention of alternatives. The fragment 'STEP — мастер' is too cryptic to function as routing guidance, leaving the agent to guess when 'export' should be chosen over the other tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context of its own — nothing about scope, what is returned, or how features are matched.

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?

It is short, but brevity here reflects under-specification rather than economy; it is not a sentence, has no front-loaded action verb, and conveys no actionable instruction.

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 required parameter, no output schema, and no sibling differentiation, the description is far too thin to let an agent invoke it correctly. Nothing compensates for the 0% schema description coverage.

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

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

Schema description coverage is 0% for the single required 'family' parameter, so the schema contributes nothing; the description's mention of holes and bolt circles weakly suggests possible feature families but never ties them to the argument. The required 'family' string remains effectively undocumented.

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 noun fragment ('Отверстия и окружности болтов.' = 'Holes and bolt circles.') with no verb and no statement of what the tool does with them. It only hints at the feature types involved, and it does not distinguish find_features from related siblings like inspect_part, measure, or locate_defects.

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?

There is no indication of when to call this tool, when to prefer an alternative, or what preconditions apply. The agent is left to guess 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the useful content signal that the check covers connection, license, build and runtime hash — which is the closest thing to a return-value summary given there is no output schema. It stops short of describing format, failure behavior, or cost.

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 short sentence with no filler, and the four checked areas are front-loaded. It is efficient, though it reads as a fragment rather than a complete statement of purpose.

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

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

With no parameters and no output schema, the description carries the burden of conveying what comes back; it enumerates the four checked areas but says nothing about the shape or meaning of the results (e.g., pass/fail, hash semantics). Combined with the covering annotations this is minimally adequate rather than complete.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly does not invent parameter guidance.

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 bare noun phrase listing the areas checked (connection to Fusion, license, build, runtime hash) rather than a verb+resource statement of what the tool does. The tool name 'health_check' supplies the action, so an agent can infer a diagnostic read, but the description itself doesn't state the purpose and does nothing to distinguish it from siblings like 'version' or 'job_status'.

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

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

There is no indication of when to call this tool versus alternatives such as 'version', 'job_status', or 'session_state'. No preconditions, no trigger context, no exclusions — the agent must guess.

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=false, idempotentHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds the useful context that import targets the currently active document, implying a session-state dependency, but says nothing about what happens on name collisions, whether existing geometry is merged or replaced, or what errors occur for unsupported formats.

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 short fragment with no wasted words, but it is under-specified rather than concise: it omits a verb and reads like a label. Being front-loaded is not enough when the sentence doesn't fully state an action.

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

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

For a mutating import tool with no output schema, 0% parameter coverage and only a fragment of a description, the agent lacks the information needed to call it confidently (required active document, name semantics, overwrite behavior). The description covers only the input formats.

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

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

Schema description coverage is 0%, so the description must compensate for the two parameters, yet it says nothing about 'path' (file location/format expectations) or 'name' (default empty, likely the resulting component/document name). The format list loosely relates to what 'path' may point at but adds no field-level 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 names the accepted formats (STEP, F3D, SMT, mesh) and the target ('active FCA document'), which conveys the import action even though the verb itself is only implied by the tool name. It does not distinguish the tool from siblings like 'assembly_add_part' or 'execute_file', which an agent might confuse with file ingestion.

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?

There is no explicit when-to-use guidance, no prerequisites (such as requiring an active/open document), and no mention of alternatives for other ingestion paths. The only usage signal is the implicit 'active FCA document' target.

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 destructiveHint false, so the safety profile is covered. The description adds that the result is a PASS/FAIL verdict, which is genuine output-shape context beyond the annotations, but it says nothing about what is compared, tolerances, or 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?

A single short sentence with zero filler and the outcome format front-loaded. It is efficient, though its brevity borders on under-specification.

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

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

For a two-parameter tool with no output schema and no schema descriptions, the definition should explain what object_name identifies, what shape expected_json takes, and what a FAIL means. None of that is present, leaving the agent unable to call the tool confidently.

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

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

Schema description coverage is 0% and the description names only expected_json, with no format or schema for that JSON. object_name, the other parameter, is never mentioned at all, so the description fails to compensate for the coverage gap.

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

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

The description states the comparison target (expected_json) and the outcome format (PASS/FAIL), but never says what is being inspected or against what fixture. In a sibling set containing validate, measure, and design_audit, the agent cannot tell what 'inspect_part' actually checks, so the purpose reads as a partial restatement of the name.

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?

There is no when-to-use, when-not-to-use, or alternative routing. Nothing distinguishes this from validate or design_audit, which an agent would plausibly consider for similar verification tasks.

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 declare readOnlyHint, idempotentHint, and non-destructive safety, so the description doesn't need to cover that. It adds the useful default scope behavior ('empty list = all document bodies'), but says nothing about return format or error conditions.

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: purpose first, then the default scope. No wasted words, well 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 an interference detection tool with two parameters and no output schema, the description is too sparse. It leaves the format of 'objects' and the effect of 'include_coincident' unexplained, so an agent cannot invoke it confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It only partially explains the 'objects' parameter (empty list means all bodies), but not its expected format, and says nothing about the 'include_coincident' parameter.

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?

States the resource (intersections of bodies) and adds a scope default (empty list = all bodies of the document). The purpose is clear, but it does not explicitly differentiate from siblings like cross_sections or measure.

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

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

Provides no guidance on when to use this tool versus alternatives such as cross_sections, compare, or locate_defects. Only the default behavior is mentioned.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered elsewhere. The description adds nothing beyond that - it does not say whether the call blocks, whether results are cached, or what the returned state values are, giving no extra behavioral context.

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

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

It is a single waste-free sentence, which is structurally sound, but the brevity stems from under-specification rather than disciplined concision, so it cannot score high on this dimension alone.

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?

There is no output schema, so the description would need to convey what a status response contains (e.g., queued/running/done/failed) and how to obtain a job_id, and it does none of this. For a status-polling endpoint these omissions leave the agent unable to interpret results correctly.

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

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

Schema description coverage is 0% for the single required parameter job_id, so the description carries the full burden of explaining it. It says nothing about where the job_id comes from (presumably execute/execute_file/render_view) or its format, leaving the parameter undocumented in both the schema and the text.

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 identifies the resource ('long-running CAM or rendering job') and implies a retrieval of its state, which is enough to guess the tool's role. However, it is a bare noun phrase with no explicit verb and no differentiation from siblings such as execute or render_view, which are the tools that presumably create these jobs.

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?

There is no guidance on when to call this tool, no mention of polling for long-running work, and no reference to alternatives or the tools that produce the job_id. The agent must infer the entire usage context from the name.

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 state readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is partially covered. The description adds no behavioral context such as permissions required, whether existing joints are modified, or what happens if links overlap. It does not contradict the annotations, but it adds nothing beyond 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 sentence fragment that lacks a subject and verb, so it is under-specified rather than concise. The list of joint types earns its place, but the overall structure fails to front-load the tool's purpose.

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

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

This is a write operation with four parameters, 0% schema description coverage, and no output schema. The description omits any explanation of the required link arguments, the limits object, or the effect of creating a joint, leaving the agent unable to call the tool correctly from the definition alone.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It effectively lists possible values for 'kind' (rigid, revolute, slider, cylindrical, pin-slot, planar, ball), which is useful, but it never mentions the required 'a' and 'b' link parameters or the optional 'limits' object. Three of four parameters receive no semantic help.

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 verbless fragment: 'Шарнир rigid, revolute, slider, cylindrical, pin-slot, planar or ball.' It names the resource (joint) and lists joint types, but never states the action, so the agent must infer 'create' from the tool name alone. It does not distinguish this tool from siblings like assembly_add_part.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The description gives no condition for choosing joint_create over any other sibling 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 by structured data. The description adds nothing beyond that: it does not say whether reading consumes/clears the error, how long the error is retained, or what the error payload looks like. It 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?

A single short sentence with no filler, front-loaded and readable. It is arguably under-specified rather than over-long, but as a zero-parameter getter the brevity is close to appropriate.

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

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

For a simple zero-parameter getter with full annotation coverage, the definition is minimally adequate. However, there is no output schema, and the tool's whole value is the shape/content of the returned error object (severity, timestamp, message), which the description never characterizes.

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 takes no parameters, so the baseline is 4. There is nothing for the description to compensate for, and no parameter confusion is possible.

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 ('Последняя ошибка runtime и Application.getLastError') is effectively a translation of the tool name 'last_error', i.e. a restatement of the resource rather than a verb+resource statement. It does add the qualifier 'runtime' and the reference to Application.getLastError, but there is no explicit 'returns/get' verb and little to distinguish it from siblings like health_check or repair_hints.

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

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

No when-to-use, when-not-to-use, or alternative guidance is given. An agent cannot tell from the text whether this should be consulted before repair_hints, after execute failures, or at any other point in the workflow.

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 without the description's help. The description adds no behavioral context at all — not what a 'timeline error' is, what triggers it, or what the agent learns from calling this. It does not contradict the annotations, but it contributes nothing beyond 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 text is short, but this is under-specification rather than conciseness — a two-word fragment carries no actionable information. Front-loading is irrelevant when there is essentially no 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 parameterless read-only probe the structured fields are simple and dedicated, so the bar is modest. Still, the description leaves the agent without any idea of what this returns or when it is the right tool, which is a real gap given the crowded sibling list.

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 takes zero parameters, so per the baseline the schema carries the full parameter burden and the description has nothing to compensate for. No parameter meaning is missing.

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 two-word noun phrase, 'Ошибки таймлайна' (Timeline errors), with no verb at all — it does not say whether the tool locates, lists, reports, or repairs defects. It gestures at the resource domain (timeline defects) but never states an action, so an agent cannot confidently distinguish it from siblings like last_error, repair_hints, or design_audit.

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?

There is no usage guidance whatsoever: no when-to-use, no when-not-to-use, and no named alternatives among the many sibling tools. Nothing tells the agent what condition should trigger this call.

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 destructiveHint=false, so the safety profile is covered. The description only adds the units of the computed outputs (mm³, mm², g), which is minimal added context and says nothing about required inputs, defaults, or 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?

It is short, but this is under-specification rather than conciseness: a telegraphic noun list with no verb, no subject, and no front-loaded purpose statement.

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 3-parameter tool with zero schema coverage and no output schema, the description should carry the full burden of explaining inputs and returns. Instead it is a one-line fragment, and it is in Russian inside an otherwise English toolset, adding friction without adding information.

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

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

All three parameters (material, object_name, density_g_cm3) have 0% schema description coverage, and the description mentions none of them. Notably density_g_cm3 is required to compute the 'mass g' it advertises, yet no link is drawn between input and output.

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 fragment lists the quantities the tool reports (volume mm³, bbox mm, area mm², mass g), which goes slightly beyond the bare name 'measure' and lets an agent infer it computes geometric properties of a part. However, there is no verb or resource and no differentiation from siblings like inspect_part, cross_sections, or analyze_printability.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. An agent cannot tell from this line whether measure or inspect_part is the right call for a given request.

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=false, idempotentHint=false, destructiveHint=false, establishing this as a non-destructive but state-changing operation. The description adds one genuinely useful behavioral fact beyond the annotations: the position is restored at the end of the sweep ("В конце положение возвращается"), which matters for downstream state assumptions. It does not, however, explain blocking behavior, motion speed/steps semantics, or whether any physical/simulated state is affected during the run.

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, front-loaded sentences with no filler; the core action leads and the state-restoration note follows. It is efficient, though the extreme brevity contributes to the coverage gaps noted elsewhere.

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, non-idempotent tool with no output schema and 0% parameter description coverage, the description is too thin. An agent cannot determine units, valid ranges, what steps does, or what the call returns or yields in terms of observable effects.

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

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

Schema description coverage is 0% across 4 parameters, so the description must carry the semantic load. It only implicitly gestures at the angle range (start/stop) and the joint, and says nothing about units, valid ranges, or what "steps" (default 24) controls. The remaining parameter meanings are undocumented in both schema and description.

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

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

"Прогон шарнира по углу" names a verb (sweep/run) and a resource (joint) plus the sweep dimension (angle), so the general action is identifiable. However, it never clarifies whether this is a simulated kinematic sweep or a physical motion, what units the angle uses, or how it differs conceptually from siblings like measure or joint_create. The purpose is only loosely pinned down.

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?

There is no statement of when this tool should be chosen over alternatives such as measure, validate, or joint_create, nor any prerequisites or exclusions. Usage must be inferred entirely from the name and the two-sentence description.

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 that this is a non-read-only, non-idempotent, non-destructive operation. The description adds no behavioral context beyond that—no permissions needed, no side effects, no return format, no naming constraints.

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

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

The description is extremely short, but it is under-specified rather than concise. It reads as a leftover fragment with no clear structure or front-loaded purpose.

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

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

For a creation tool with two parameters, zero schema description coverage, no output schema, and many sibling tools, the description is far too thin. It omits prerequisites, return behavior, naming rules, and any distinction from related creation/import 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?

Schema description coverage is 0%, so the description must compensate for both parameters. It hints at naming via FCA_<имя> and possibly design_intent via 'Hybrid', but does not explain the design_intent parameter, its allowed values, or the role of name beyond a placeholder.

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 cryptic fragment naming a document format (FCA_<name>, Parametric, Hybrid, millimeters) rather than stating what the tool does. It does not clearly say 'create a new design document' nor distinguish this tool from sibling CAD-creation tools like import_cad_file.

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?

There is no guidance on when to use this tool, when not to, or what alternatives exist. The agent is left to infer usage entirely from the name 'new_design'.

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 word 'diff' weakly suggests a comparison behavior, but the description adds no real context about side effects, scoping, or what the diff is against beyond what annotations supply, so it stays near 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?

It is short, but shortness here reflects under-specification rather than economical structure. The single fragment is not front-loaded with a clear purpose and mixes two concepts without explaining either.

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

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

For a tool with an undocumented parameter, no output schema, and a crowded sibling set, this description leaves out almost everything an agent needs: what user parameters are retrieved, what the diff compares, and when to choose this over params_set.

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 is a single parameter ('model') with 0% schema description coverage, and the description only vaguely alludes to a 'dataclass модели'. It does not explain what value the model parameter takes, whether it is optional, or how it affects the result, so it fails to compensate for the coverage gap.

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

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

The description is a near-tautology that largely restates the name: 'User parameters и diff с dataclass модели' hints at reading user parameters and a diff against a dataclass model, but it never states a clear verb+resource or distinguishes itself from the sibling params_set. An agent cannot confidently tell what this returns or how it differs from params_set.

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?

There is no when-to-use or when-not-to-use guidance, no mention of the sibling params_set as the write counterpart, and no preconditions. The agent is left to infer everything 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 declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds essentially nothing beyond that: it does not say whether changes persist, whether they apply immediately, or what happens to unlisted parameters. It does not contradict the annotations, but it carries little extra weight.

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, front-loaded sentences with no filler; the value format is stated compactly. It is efficient, though terseness here is close to under-specification rather than true conciseness.

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

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

A mutation tool with a nested free-form object parameter, no output schema, and 0% schema coverage needs more from the description than 'changes parameters'. Valid parameter names, the meaning of 'unit', and any confirmation/return behavior are all missing.

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

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

Schema description coverage is 0% and the single parameter is a free-form object with additionalProperties=true, so the schema documents nothing. The description compensates partially by specifying the shape of each entry ('{value, unit}'), which is genuinely useful, but it never names valid parameter keys or units, leaving the core question of what can be set unanswered.

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 gives a verb+resource ('Меняет параметры' / changes parameters) but no scope, no indication of which parameters, and no differentiation from the sibling params_get beyond the implicit set-vs-get verb. An agent can guess it is the write counterpart to params_get, but the description itself does not make that 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?

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative params_get. The agent must infer routing from the tool name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description does add two useful behavioral facts beyond the annotations: a file is written into renders/ and the same image is returned inline as base64. It says nothing about camera defaults, resolution handling, or failure 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 single sentence is compact and wastes no words, but that brevity comes from under-specification rather than tight editing – there is no structure for an agent to parse beyond the output statement.

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 an 11-parameter tool with no output schema, no parameter descriptions anywhere, and a terse non-English fragment, the definition omits almost everything an agent needs to call 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?

Eleven parameters with 0% schema description coverage (colors, objects, save_to, width_px, height_px, direction, azimuth_deg, elevation_deg, clip_axis, clip_at_mm, highlights) and the description gives no meaning, format, or defaults for any of them. This is the largest gap.

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

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

The description only names the output artifacts ('PNG в renders/ и base64 в ответе') and never states the subject of the render – a 2D view, 3D view, or drawing of the design. It largely restates the name 'render_view' plus delivery format, so an agent cannot tell what it produces beyond a PNG.

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?

There is no when-to-use guidance, no mention of alternatives among the many sibling visualization/inspection tools (measure, cross_sections, inspect_part, export), and no preconditions 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond that—no output shape, no indication of how the hint is derived, and no limitations on the lookup.

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?

It is a single short sentence with no filler, and the error-text focus is front-loaded. However, the brevity comes at the cost of useful detail rather than being efficient coverage.

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?

There is no output schema, yet the description does not explain what a repair hint contains or how it should be used. For a tool with two parameters and zero schema descriptions, the definition is materially incomplete.

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

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

Schema description coverage is 0%, so the schema does not explain either parameter. The description hints that error_text is the input, but it does not define its expected format or explain the optional 'goal' parameter at all, leaving half the parameters undocumented in both structured and unstructured form.

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 'Подсказка по тексту ошибки Fusion' largely restates the tool name (repair_hints) and only adds that the input is a Fusion error text. It does not state a clear verb, what kind of repair hint is produced, or distinguish this tool from siblings such as last_error or workflow_hints.

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

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

No when-to-use guidance is provided. The description does not say whether to call this after last_error, when to prefer it over workflow_hints, or what prerequisites exist for obtaining a useful hint.

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, idempotentHint=false and readOnlyHint=false, so safety is covered. The description adds genuine scope context — what is destroyed (the timeline) and that only the FCA document is affected — but says nothing about reversibility, undo, or authorization requirements beyond the confirm flag.

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, zero filler, with the destructive scope stated first and the precondition second. Nothing could be removed without losing 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 destructive, non-idempotent operation with no output schema and no undoing story, the description covers the trigger and the confirm gate but leaves the meaning of 'FCA document' and the consequences/irreversibility of the reset unstated. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must carry the load for the single parameter. It does add meaning: the schema only marks 'confirm' as required, while the description specifies it must be true, clarifying the required value rather than mere presence.

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 gives a specific verb and resource ('Очищает таймлайн') plus a scope qualifier ('только FCA-документа'), which rescues the otherwise generic name 'reset'. It does not, however, differentiate against any named sibling, so an agent must infer that no listed tool duplicates this behavior.

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 only usage statement is 'Нужен confirm=true', which is a parameter precondition rather than when-to-use guidance. There is no indication of when a reset is appropriate versus alternatives like restore_snapshot or new_design, and no warning about when not to use it.

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

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

Annotations state readOnlyHint=false, idempotentHint=true, and destructiveHint=false, but the description adds no behavioral context beyond those structured fields. It does not explain what mutation or side effect occurs, what permissions may be needed, or what the tool returns.

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 text is short, but it is under-specified rather than concise. A single ambiguous noun phrase does not front-load a usable action or purpose.

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

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

For a three-parameter tool with no output schema and only minimal annotations, the description is far too incomplete. It leaves the core operation, required inputs, and expected outcome unexplained.

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

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

Schema description coverage is 0%, so the description must compensate for three parameters, but it does not. It mentions selector, yet omits object_name and label entirely, and references 'attribute' and 'entityToken' which are not even schema 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 is only a terse noun list: 'Селектор, атрибут и entityToken' (Selector, attribute and entityToken). It gives no verb or clear operation, so an agent cannot confidently tell what 'resolve' actually does or how it differs from sibling tools like find_features or locate_defects.

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?

There is no when-to-use guidance, no preconditions, and no mention of alternatives. The description does not help an agent decide whether to call resolve instead of find_features, inspect_part, or any other sibling.

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=false, idempotentHint=true, destructiveHint=false, so the safety profile is partly covered and the description is not required to repeat it. However, the description adds nothing at all: it does not say whose state is reverted, whether unsaved work is lost, or that restoring an unknown name fails. "Откат" (rollback) semantically suggests state replacement, which sits uneasily with destructiveHint=false, yet the text never resolves that tension.

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 short sentence with zero filler and the action front-loaded — structurally clean. But the brevity is achieved by omission rather than by precision, so it is under-specified rather than truly concise.

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

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

For a state-mutating restore operation with an undocumented required parameter, no output schema, and no annotations covering reversibility or error behavior, this description leaves essentially everything an agent needs unresolved.

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?

One parameter ("name") with 0% schema description coverage, so the description must carry the burden. The phrase "к снимку" only weakly implies that name identifies the target snapshot; it never states the expected format (ID vs label), or what happens when it does not match an existing snapshot.

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?

"Откат к снимку" names a specific verb (rollback) and resource (snapshot), so the action is identifiable. But it gives no scope detail — which snapshot, what state is restored, over what target — and does nothing to distinguish it from sibling save_snapshot. Vague-but-legible purpose, which is the definition of a 3.

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?

There is no when-to-use, no when-not-to-use, no prerequisite, and no mention of the obvious alternative save_snapshot. The agent is given no basis for choosing this tool over its siblings.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the scope of captured data and says nothing about overwrite semantics for an existing 'name', permissions, or session requirements, so it contributes little beyond 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?

It is a single short sentence with no padding, but it is an incomplete fragment rather than a front-loaded statement of purpose and behavior. Brevity here reflects under-specification rather than disciplined conciseness.

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

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

For a write tool with no output schema and an undocumented parameter, the description omits the action verb, the parameter meaning, and any usage context. An agent would know what data is captured but not how to invoke it correctly or when.

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

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

The single required parameter 'name' has 0% schema description coverage and the description never mentions it, so its meaning (snapshot identifier, uniqueness, overwrite behavior) is left undocumented in both places. With low coverage the description was expected to compensate and does not.

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 fragment names the captured content (expressions, timeline marker, metrics) which implies a snapshot write, but it is a noun phrase with no verb and relies on the tool name 'save_snapshot' to convey the action. It loosely distinguishes from the sibling 'restore_snapshot', but never states the saving action explicitly.

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?

There is no guidance on when to save a snapshot versus restoring one, no mention of prerequisites (e.g., an active design/session), and no reference to the sibling 'restore_snapshot' as the counterpart operation. The agent must infer usage entirely.

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 by structured data. The description adds the useful fact that this exposes the history of executed 'execute' blocks, but says nothing about log scope, ordering, retention, or whether it is per-session.

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 short sentence with no filler or repetition, and the resource is front-loaded. It is efficient, though its brevity edges into under-specification rather than being optimally sized for the tool's role.

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

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

With no output schema and no parameters, the description carries the burden of explaining what is returned, yet it never describes the log's contents, format, or granularity. For a history/journal tool this leaves the agent guessing about what a call actually yields.

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 takes zero parameters and the schema is empty with 100% coverage, so the baseline is 4. There is nothing parameter-related for the description to clarify, and it does not attempt to invent filters that do not exist.

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 phrase 'Журнал выполненных блоков execute' identifies a resource (a journal/log of executed execute blocks), which is more than a tautology of the name 'script'. However, it never states the action (retrieve/read) explicitly and gives no hint of how it differs from siblings like job_status, last_error, or session_state, which similarly expose execution history.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as job_status or last_error that an agent would plausibly confuse with an execution log. The agent must infer usage purely from the noun phrase.

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 fully covered by structured data. The description adds only a fragmentary hint that it concerns the active document, bodies, and the execute space, which is weak context and no real behavioral disclosure beyond 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?

It is short, but it is an under-specified sentence fragment rather than an efficient front-loaded statement. Length is not earned by content because the fragment conveys almost nothing actionable.

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

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

With no parameters, no output schema, and no annotations beyond safety hints, the description carries the burden of explaining what state is returned. It only gestures at 'active FCA document, bodies, execute space' without saying what the agent receives or how to use it, leaving the definition substantially incomplete.

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

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

The tool takes zero parameters, so the description has no parameter semantics to explain; the baseline of 4 applies. The input schema is empty and fully documented.

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 bare noun phrase ('Active FCA document, bodies and execute space') with no verb and no statement of what the tool does. It vaguely gestures at returned state but never says this tool reads or reports session state, so an agent cannot confidently distinguish it from siblings like script, health_check, or version.

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?

There is no when-to-use guidance, no prerequisites, and no mention of any alternative tool. The agent is given nothing to decide whether session_state or another sibling should be invoked.

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/destructiveHint=false, so safety is covered. The only behavioral hint is 'deep проверяет STEP', which implies a heavier check mode, but the description says nothing about cost, failure modes, or what a 'timeline health' result means.

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?

It is short, but it is short by being an unpunctuated fragment list rather than a front-loaded, informative sentence. Brevity here reflects under-specification, not economy.

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 two undocumented parameters, no output schema, and many overlapping siblings, the description leaves critical gaps: what is validated, what a result contains, and how it differs from the other check/audit 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?

With 0% schema description coverage, the description must carry both parameters. It only hints at 'deep' (checks STEP) while object_name is entirely undocumented, leaving the agent to guess what object is being validated.

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 fragment list ('Timeline health, solid, volume') rather than a verb+resource statement, so it never says what validate actually does or returns. It gestures at what is inspected but never states the action, and it does not distinguish itself from validation-adjacent siblings like health_check, design_audit, or inspect_part.

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

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

No when-to-use, when-not-to-use, or alternative is given. An agent choosing between validate, health_check, design_audit, and inspect_part gets no routing signal at all.

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 destructiveHint=false, so the safety profile is covered. The description adds one piece of non-redundant context: that two version values (package and converter) are returned, which hints at the return content. It says nothing about format or error behavior, but with annotations carrying the safety burden 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 short sentence with no filler, front-loading the resource. It is minimally sized for a trivial tool, though it is terse enough that it reads more like a label than an instruction.

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

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

For a zero-parameter, read-only lookup with no output schema, the description covers what an agent needs: the identity of the returned values. Only the exact return shape/format is unspecified, which is a minor gap for so simple a 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 tool takes zero parameters and schema coverage is 100% (empty properties object), so the baseline of 4 applies. There is nothing for the description to clarify about arguments.

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

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

The description names the resource clearly — the version of the fusion-cad-ai package and its converter — so an agent can tell what information is returned. The verb is only implied (a version query), and it does not explicitly distinguish itself from sibling diagnostics like health_check, but the resource is specific enough to identify the 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?

There is no statement of when to call this versus alternatives such as health_check or last_error, and no prerequisites or exclusions. The name and description imply a diagnostic lookup, but usage is left entirely to 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, so the safety profile is fully covered by structured data. The description adds only a vague topical scope and nothing about what the call returns or when it is meaningful. It does not contradict the annotations, but it contributes almost no behavioral context beyond 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?

It is very short and front-loaded, with no filler. However, the brevity reflects under-specification rather than disciplined concision — there is no sentence that conveys actionable purpose, so the size is not really 'earned'.

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

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

For a zero-parameter read-only helper with no output schema, the description carries the entire burden of explaining what the call returns and when to make it, and it fails to do so. It also switches to Russian while the toolset and sibling names are English, which weakens discoverability. An agent cannot tell from this text what it would get back.

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side, and the empty schema is self-explanatory.

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

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

The description reads as a topic label ('BUILD → VERIFY cycle and unit rules') rather than a purpose statement. It never says what the tool actually does (presumably return workflow/unit-convention hints), and reads partly as a paraphrase of its own name. It also gives no signal distinguishing it from the many other hint/help-style 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?

There is no when-to-use guidance at all — no condition, trigger, or exclusion. Notably, the sibling 'repair_hints' exists and the description does nothing to route an agent between the two. The only implicit cue is the word 'BUILD → VERIFY', which a caller must guess at.

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