Guides the BUILD → VERIFY cycle and enforces unit rules for Fusion CAD workflows, enabling agents to validate parts and assemblies against millimeter-based parameters.
Цикл BUILD → VERIFY и правила единиц.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v2.0.0Does 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.