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

No annotations are provided, so the description carries the full burden. It does disclose real behavioral semantics the schema lacks — that `count` includes the original instance and that `angle` is a total span rather than a per-instance increment — which prevents off-by-one patterning errors. It says nothing about permissions, whether the pattern is reversible, or the relationship to the sibling `transaction` tool, which are significant gaps for a model-mutating operation.

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

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

Front-loads the action in one sentence, follows with a motivating example, then a tight Args block. Every line carries usable information; the minor restatement of defaults is inherent to docstring formatting and costs nothing.

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?

An output schema exists, so return values need no explanation, and all meaningful parameters receive semantic treatment. For a single-purpose feature-creation call this is complete enough to invoke correctly on the first try, with only transaction/undo behavior left implicit.

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 only 20% (just `instance`), so the description must compensate and largely does: `feature_index` is sourced from `list_features()`, `count` is defined as total including the original, `angle` as total span with 360 meaning full circle, and `axis` constrained to X/Y/Z with a flange-oriented default. Only `instance` is left to the schema, which already documents it.

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?

Uses a specific verb and resource ('Create a circular (rotational) pattern of a feature') and scopes it to a work axis, so the action is unambiguous. It does not, however, differentiate itself from the sibling `draw_pattern`, which an agent could plausibly reach for instead — that differentiation is the only missing piece.

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 bolt-hole/flange example gives a concrete usage context and even a rationale ('one hole + add_circular_pattern instead of 8 holes'), which is more than bare implication. But there are no exclusion conditions and no mention of when `draw_pattern` or manual duplication would be the right choice, so the agent must infer the boundaries.

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

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

No annotations exist, so the description carries the full burden. It does disclose a non-obvious behavior — the round is carried into the flat pattern — and that the target is sheet metal corner edges. It omits prerequisites (must the document be a sheet metal part?), error behavior, and reversibility, which matters for a mutation tool.

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

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

Front-loaded with the purpose and usage in two short lines, then a compact Args block. No wasted sentences, though the Args structure largely restates schema fields.

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

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

An output schema exists, so return values need no explanation. However, the description never says how to obtain valid edge indices (the sibling find_edges) nor whether a flat-pattern-bearing sheet metal document is required, which is the main practical blocker for a correct call.

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

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

Schema coverage is only 33%, but the description compensates for the two undocumented parameters: it explains edge_indices as comma-separated short edges through the thickness at corners and gives units (mm) for radius. The 'through the thickness' phrasing adds real meaning beyond the schema and helps disambiguate which edges qualify.

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 definition gives a specific verb-plus-resource ('Round sharp sheet metal corners') and names the underlying feature (Corner Round) plus its flat-pattern behavior. It is clearly distinct from generic modeling siblings, though it never names its closest alternatives (fillet, chamfer) to draw the boundary 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?

One positive usage cue is given: 'Use on exposed corners people handle, e.g. mounting plate tabs.' That is genuinely helpful but purely inclusive — there is no when-not guidance and no pointer to fillet/chamfer/find_edges as the route for other geometry, so the agent must infer the boundary.

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

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

With no annotations, the description carries the burden and discloses key behavior: proper bend radius, Flat Pattern support, auto-mitering semantics, and the bend-direction rule based on the edge's face side. It does not describe document prerequisites or failure behavior, but the major geometric side effects are well covered.

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 front-loaded with purpose and critical usage constraints, then uses a compact Args block. Although it repeats schema defaults, those repetitions are paired with units and semantic meaning, so they earn their place for a seven-parameter CAD feature.

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?

An output schema exists, so the description need not explain return values. It covers the operation, edge batching, bend direction, and most parameter semantics, but omits the instance parameter and any document/sheet-metal-rule prerequisites, leaving minor operational 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 only 14%, but the description compensates by documenting six of seven parameters: edge_indices format and find_edges usage, distance in mm, angle in degrees, auto_miter, miter_gap expression semantics, and height_datum options. The remaining instance parameter is documented in the schema itself.

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 specific verb and resource ("Add a Sheet Metal Flange") and scope (one or more edges), and explicitly distinguishes it from Extrude. It also explains the sheet-metal-specific behavior (Flat Pattern, bend radius, thickness tie), so an agent can tell what kind of feature this creates.

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?

Names Extrude as the non-sheet-metal alternative and gives a concrete batching rule: put all loop edges in one call so corners auto-miter, because separate calls leave open corners. It also points to find_edges for edge discovery. It does not explicitly state when not to use this tool, but the routing context is clear.

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

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

With no annotations, the description carries the full burden and does well: it discloses that new part files are created (one per profile/length, reused across members), where they go, and that the return includes placements plus a saw-cut list. It does not cover failure modes or transactional/undo behavior, which keeps it short of a 5.

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?

Purpose leads, then behavior, then a clearly delimited Args block, so it is well front-loaded. It is dense and largely earns its length, though the profile-family examples and roll/anchor asides could be trimmed slightly 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 complex geometry-creating tool with an output schema, the description supplies units, defaults, per-member overrides, file side effects, and verification steps. Nothing an agent needs in order to call it correctly on the first attempt is missing.

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

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

Schema coverage is only 17%, but the description compensates thoroughly: it documents the members array shape, units (mm), and optional per-member keys (family, size, category, roll, anchor, extend) with semantics and examples. The one undocumented parameter, instance, is covered by its own schema description, so nothing is left ambiguous.

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

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

States a specific verb and resource: builds steel frame members as Content Center custom-length profiles along skeleton lines in the active assembly. It explicitly distinguishes itself from place_components and use_content_center by explaining that this is what Frame Generator does and that Frame Generator has no API.

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?

Points the agent to use_content_center for the profile defaults and to capture_view to verify placements after the call. It gives clear operating context (active assembly, skeleton lines) but does not explicitly exclude alternatives such as place_components for non-structural component placement.

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

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

With no annotations provided, the description carries the burden and discloses meaningful behavior: it adds to the active part, fails rather than leaving an empty feature when no material is removed, and clarifies coordinate and associativity semantics for each placement mode. These details go well beyond the schema.

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 front-loaded with the core action and failure behavior, then organizes placement modes and arguments into scannable sections. It is long but every section adds needed guidance for a 12-parameter modeling operation.

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

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

Given a complex mutation tool with no annotations, low schema description coverage, and 12 parameters, the description supplies the missing operational context: active-part scope, failure behavior, placement alternatives, and argument meaning. Output semantics need not be repeated because an output schema exists.

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 only 8%, so the description must compensate, and it largely does: it explains diameter, depth, tapped, pitch, counterbore fields, x/y, point/direction, and the linear object with an example. Only instance is omitted from the description, and that parameter already has schema-level explanation.

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: adds a native hole feature to the active part, including drilled, tapped, and counterbored variants. It is clear what the tool does, but it does not explicitly distinguish this tool from related modeling siblings such as sheet_metal_cut or extrude.

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

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

It provides clear contextual guidance for choosing among three placement modes, including 'Safest' for point+direction and 'preferred for fastener holes' for linear placement. It does not explicitly state when not to use this tool or name alternative tools for non-hole material removal.

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

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

With no annotations, the description carries the full behavioral burden, and it does add one valuable disclosure: thickness is taken automatically from the style rather than from a parameter. It says nothing about required preconditions (valid sheet metal style, closed non-self-intersecting profile) or failure behavior, leaving meaningful gaps for a mutation tool.

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

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

Three short sentences, front-loaded with the action and its scope. The clause about automatic thickness could be folded into the first sentence, but there is no filler.

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

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

An output schema exists, so return values need not be explained, and the two-parameter surface is small. Still, an agent lacks the preconditions for a successful call (sheet metal environment, closed profile, style availability) and any hint of what `sketch_index` addresses.

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

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

Schema coverage is only 50%: `instance` is documented in-schema but `sketch_index` has no description anywhere. The description's mention of a "closed sketch profile" gestures at the sketch input but never explains that the index selects a sketch from the model tree, so it fails to compensate for the 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?

States a specific verb and resource ("Create a base Sheet Metal Face") and clarifies it is the first flat panel of a sheet metal part, which implicitly separates it from follow-on features like add_flange or sheet_metal_cut. It does not name any sibling explicitly, so it lands just short of a 5.

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

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

"The first flat panel in a sheet metal part" implies when to reach for this tool (the initial face, before flanges/cuts), but the description never states prerequisites such as a sheet metal style being active or a closed profile existing, nor does it name alternatives. Usage must be inferred.

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

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

With no annotations present, the description carries the burden and does real work: it discloses token cost per image, that sketches/work features are hidden by default and "restored after", and that isolate hides other components only "for the picture" — i.e. these are temporary view-state changes, not persistent edits. It does not say whether the document is left modified or whether the view orientation is restored.

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?

Purpose and the return type are front-loaded in the first line, the use-case follows, then args — no wasted sentences. The failure-mode examples (wrong-side flange, floating part) look decorative but directly explain why images beat numbers, so they earn their space.

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 9-parameter, no-annotation, no-output-schema tool, this is nearly complete: every parameter except `instance` is explained, cost and temporary-state behavior are disclosed, and the return type (images) is stated. The one real gap is that it does not say how multiple requested views map to returned images (count/order), which matters when batching iso,front,top.

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

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

Schema coverage is only 11% (just `instance`), so the description must compensate and does: it enumerates the valid `views` tokens with an example, explains `fit_to` vs `isolate` as zoom-to vs show-only with the inside-components behavior, clarifies `up` semantics (Y-up template default vs Z-up models, with the axis each named view faces), and gives unit/cost meaning for width/height. Only `instance` is uncovered, and the schema documents it.

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 specific verb and resource — renders pictures of the active document returned as viewable images — and frames it against numeric inspection ("which the numbers alone don't show"), which separates it from inspect_model/measure_distance/check_interference. An agent knows immediately what it gets back: images, not data.

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?

Gives concrete when-to-use cues (verify a flange orientation, a door swing, a part floating off the frame) and a cost warning ("keep them modest — each picture costs tokens"). It never names an alternative tool or states when not to call it, so it stops short of full routing guidance.

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

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

With no annotations at all, the description carries the full burden yet says nothing about whether the operation modifies the model irreversibly, whether it fails on invalid edge indices, or whether it requires an active document. It does disclose units (mm), which is useful, but leaves the mutation behavior opaque.

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?

Front-loaded single-sentence purpose followed by a brief Args block; nothing is wasted. There is minor redundancy in repeating 'Distance in mm' in the args line.

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

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

An output schema exists, so return values need no explanation. However, for an unannotated mutation tool, missing prerequisites (active part document, valid edge discovery) and failure behavior leave the definition only minimally sufficient.

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

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

Schema coverage is only 33%, and the description compensates for the two undocumented params by defining `distance` as mm and giving the comma-separated format with an example for `edge_indices`. The third param, `instance`, is only covered by the schema, so semantics are adequate but not complete.

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

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

The description names a specific verb and resource — 'Add chamfer (angled edge) to edges of the solid body' — and the parenthetical definition disambiguates it from a generic edge operation. It does not explicitly contrast with the sibling `fillet` (rounded vs angled), so an agent must infer that distinction.

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

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

It never states when to use this versus `fillet` or other edge-modification tools, nor that edge indices must first be obtained via `list_edges`/`find_edge`. It also omits the prerequisite that an active solid part must exist, leaving only implicit 'use this to chamfer' guidance.

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

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

With no annotations the description carries the burden, and it delivers meaningful behavior: touching contact is excluded, intentional overlaps are still reported, and fastener overlaps are set aside but still counted. It doesn't state whether the tool is read-only or what cost/latency a full-assembly sweep incurs, which keeps it from a 5.

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 core capability and its caveats are front-loaded in the first two sentences, then per-argument detail follows. Slightly verbose with docstring artifacts (stray backslashes, empty lines) but no sentence is genuinely wasted.

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

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

An output schema exists, so return values needn't be spelled out, and the description still points at volume/bbox as the interpretation key. For a 4-param, unannotated query tool it covers the decision-relevant behavior; only the `instance` selector and any performance/read-only framing are unaddressed.

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

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

Schema coverage is only 25% (just `instance`), so the description must compensate — and it does, giving concrete syntax for set_a/set_b ('DOOR:1', 'Sub:1/Part:2', '*BRACKET*') and the 150 mm threshold semantics of ignore_fasteners. `instance` is left entirely to the schema, a small 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?

States a specific verb+resource ('check overlap between occurrences of the active assembly') and even names what it returns (full paths, volume, bounding box). No sibling in the list does interference checking, so an agent can route to it unambiguously.

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?

Explains how to interpret results ('intended overlaps ... show up too — read the volume and bbox') and the key exclusion rule (touching faces not reported), plus 'empty = everything else' for set_b. It does not explicitly contrast with alternatives like measure_distance, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the burden. It does disclose return content (sketch coordinates in mm, profile success, closed-loop count), which is useful, but it never states that the operation is read-only or that it leaves the sketch untouched, nor any permission/precondition behavior. Given an output schema already exists, the description adds diagnostic context but leaves the safety/mutation profile unstated.

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?

Front-loaded with the motivating question followed by a compact enumeration of checks, then the arg note. Efficient overall; the nested parentheticals ('overlaps, stray lines') add slight density but each clause carries informational value.

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

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

For a two-param read/diagnostic tool with an output schema, the description covers what it checks, the coordinate unit, and the key result (whether a profile builds and loop count). Instance-selection guidance lives in the schema, so the definition is nearly complete; only explicit read-only/state semantics are missing.

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

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

Schema coverage is 50%: 'instance' is documented in the schema, while 'sketch_index' is not. The description compensates with 'Sketch number (0 = latest sketch)', giving real meaning beyond the schema's bare default. This is solid coverage of the undocumented 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?

Opens with a concrete use case ('Why won't it extrude?') and then enumerates exactly what it inspects: open ends, near-miss gaps, 3+ curve junctions, duplicate lines, plus profile build status and closed-loop count. This is a specific verb+resource that an agent can clearly distinguish from siblings like extrude or revolve.

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?

'Why won't it extrude?' plus 'extrude / revolve report the same when they fail' implies when to call it (diagnosing failed extrusion/revolve). However, it doesn't give an explicit routing rule such as 'call this before/after extrude fails' or state exclusions, so guidance is strong but not fully spelled out.

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

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

With no annotations, the description carries the full burden and discloses key behavior: it starts Inventor if none is running, may reuse an existing or previously started instance, may start a separate one for project isolation, and returns an instance name that must be reused later. This is unusually rich context for a connection-management tool.

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

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

The first sentence is front-loaded and the Args section is structured. The project/instance explanation is valuable but somewhat dense; it could be tightened slightly, but it earns most of its space.

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

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

Given an output schema exists, the description need not explain return values. It covers lifecycle behavior, project isolation, instance naming, and the role of each parameter well enough for an agent to call 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 only 20%, so the description must compensate. It documents visible, project (.ipj full path), new_instance, and pid (kept Inventor shown by list_instances), and the schema supplies the instance name semantics. This adds substantial meaning beyond raw parameter names.

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

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

The description states a specific verb and resource: 'Connect to Autodesk Inventor', and clarifies the startup behavior. It does not explicitly compare itself to siblings like list_instances or status, but the purpose is clear from the name and opening.

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

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

It gives clear context for when to pass a project path, when the server reuses versus starts an Inventor instance, and when to pass an instance name later. It lacks explicit 'do not use if already connected' guidance, but the operational context is strong.

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

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

With no annotations, the description carries the full load and does well: it warns that a constraint 'can drag parts you didn't mean to touch' and that the tool reports which components moved, and it discloses the offset-sign retry behavior ('tried with the other sign'). It doesn't say whether constraints are persistent/undoable or what a failure looks like, so not a 5.

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 key insight (prefer origin geometry) is front-loaded and every section — References, Says, Args — adds information. It's dense and useful rather than padded, though the reference-format line is a wall of syntax that could be organized more scannably.

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 8-parameter mutation tool with no annotations, the description covers reference syntax, kind semantics, both dimensional parameters, the a_at landing check, and the axes_opposed insert case. An output schema exists, so the return-reporting note is a bonus rather than a gap.

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

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

Schema coverage is only 13%, so the description must compensate — and it largely does, explaining a vs b's roles, all four `kind` values, units for `offset` and `angle`, and giving a concrete `a_at` example ({"Z": 182.5}). The only undocumented parameter is `instance`, which the schema itself covers via its own description, so the gap is minor but prevents a 5.

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

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

States a specific verb and resource — 'Constrain two components' — plus the supported reference types (origin geometry, faces, circular edges) and depth-independence. It's clear what it does, but it never distinguishes itself from the sibling `manage_constraints`, leaving the agent to guess whether that tool lists/edits/deletes constraints while this one creates them.

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?

Gives real selection guidance: 'Prefer origin geometry: it survives part edits; face and edge numbers change with the topology,' which is exactly the kind of tradeoff an agent needs. It also implies the workflow by naming `find_faces` and `find_edges` as the source of face/edge references. Falls short of 5 because it doesn't say when *not* to use this tool or how it differs from `manage_constraints`.

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

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

With no annotations, the description carries the disclosure burden and does reasonably well: it explains the staged behavior (stitch → patch → close), the closed-shell shortcut, that it reports each step plus resulting volumes, and that it surfaces open edges it could not close with mm coordinates. It omits what happens to the original surface bodies after conversion (replaced, consumed, or left behind), which matters for a shell-closing operation.

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

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

Front-loaded with the outcome and scenario before any mechanics, and the Args block is scannable. A few phrases ('so no mass and no booleans') are color rather than instruction, and the Args formatting is slightly verbose, but nothing is redundant or misleading.

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

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

Given 4 optional params, 25% schema coverage, no annotations, and an output schema that already covers return values, the description supplies exactly what's missing: the failure mode (unclosed open edges), unit conventions, grouping strategy, and the run-context prerequisite. An agent can invoke this correctly from the description 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 coverage is only 25% (only 'instance' is documented), but the Args block compensates strongly: work_surfaces accepts 'all' or numbered groups '1,2,5' with a rationale, tolerance is defined as the largest gap to stitch in mm, and patch_holes is explained as filling loops of open edges with a boundary patch. Only 'instance' is left to the schema, so the description adds real meaning over the raw property names.

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

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

States a specific verb+resource ('Turn surfaces into solids') and immediately grounds it in the real scenario: imported vendor models (x_t, IGES, STEP) arriving as faces with no volume, mass, or boolean capability. It also enumerates the concrete operations (stitch, patch holes, close shell) so an agent can distinguish this from import_step or generic feature tools 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?

Gives clear operating context: 'Run it in the part that holds the surfaces' and converts 'one group at a time (e.g. one component of a multi-part import)'. That establishes the prerequisite and a sensible batching strategy, but it never names an alternative sibling (e.g. import_step for fresh imports) or states when-not to use it, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that material and part number are populated immediately and explains template/metric/english choices, but it does not state whether the document is saved, opened, or requires an active connection, nor does it describe permissions or side effects.

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

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

The description is front-loaded with the core purpose and rationale, then uses a clean Args list for parameter details. Every sentence adds useful information without repetition.

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

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

The output schema exists, and the description documents most parameters and the main use case well. However, for a creation tool with no annotations, it should say more about persistence, side effects, or connection requirements.

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

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

Schema coverage is only 14%, but the description compensates strongly: it defines allowed kind values, template options ('metric', 'english', or a template path), material library syntax, and the meaning of part_number and description as BOM iProperties. The one undocumented parameter, instance, already has a schema description.

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

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

The description uses a specific verb and resource: 'Create a new document,' and clarifies that it creates a part, sheet metal part, or assembly with material and part number populated. It does not explicitly distinguish itself from siblings like create_drawing or manage_documents, so it falls short of a 5.

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

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

The description gives a rationale ('so no part is left Generic for the BOM and the mass') but does not state when to use this tool versus alternatives such as manage_documents, create_drawing, or save_document. There are no exclusions 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?

With no annotations, the description carries the full burden and mostly succeeds: it discloses that files are written to disk, that the drawing is closed unless drawing_path is supplied (a real persistence side effect), that the title block is auto-filled from properties(), and that retrieved model dimensions and overall dimensions may need checking on assemblies. It does not mention overwrite behavior or required permissions.

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

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

Front-loaded with the deliverable, then a compact Args block that maps one-to-one to parameters. Slightly dense in the layout/dimension sentence, but no filler.

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

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

For a 7-parameter file-producing tool with no annotations, this covers output location, persistence, view composition and template behavior well; an output schema exists, so return values need not be explained. Minor gaps remain around overwriting an existing pdf_path and error behavior for invalid view names.

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 only 14%, so the description must compensate and does: views ordering and placement semantics, template naming and .idw path form, scale encoding (0 = fit, 0.2 = 1:5), flat = single-view flat pattern, and drawing_path persistence are all explained. Only instance is left to the schema, which documents it adequately.

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

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

Opens with a specific verb, resource and deliverable: a 2D drawing of the active part/assembly saved to disk and exported as PDF. This is clearly distinguishable from sibling tools such as capture_view (screenshots) or export_document (generic export).

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?

Usage context is implied ("PDF for the shop floor", flat-pattern mode for sheet metal parts) rather than stated as when-to-use versus siblings like capture_view or export_document. The closing instruction to read the PDF back to check layout is useful post-call guidance but is not an alternative-selection rule.

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

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

With no annotations, the description carries the full burden. It discloses key geometry behavior: how face_index overrides plane, the 1-based face indexing, and offset direction conventions per plane. However, it does not state document-state requirements, side effects such as whether the sketch becomes active, 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?

The primary action is front-loaded in the first sentence, followed by an Args section that is dense and free of repetition. Every clause conveys operational meaning, including the per-plane offset direction shorthand.

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?

An output schema exists, so return values need not be described. The description covers the non-obvious geometry semantics of all three primary parameters and delegates instance selection to the schema. It stops short of stating document prerequisites or whether the new sketch becomes the active sketch, which would matter for a mutation tool with no annotations.

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

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

Schema coverage is only 25%, but the description compensates strongly: it supplies plane enum values, explains the 0 sentinel for face_index, defines offset units and sign convention per plane, and clarifies the plane/face precedence. The remaining instance parameter is already documented in the schema.

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

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

States a specific verb and resource ('Create a new sketch') and enumerates the three supported placement targets: work plane, body face, or offset work plane. This distinguishes it clearly from sibling drawing tools such as draw_rectangle and draw_circle.

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?

Explains the selection logic between plane and face_index ('Ignored if face_index > 0') and points to list_faces() for locating a face. It also gives a concrete use case for offset ('For ribs/bosses at a height'), though it does not explicitly state prerequisites such as needing an active part document.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses units (mm), arc direction (counter-clockwise in sketch coordinates), two mutually exclusive construction modes (through a point or around a center), and the geometric constraint that start/end must be equidistant from the center. It omits prerequisites such as needing an active sketch/document and how failures surface.

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?

Front-loaded with the core action and a usage example, then a compact Args block that adds meaning rather than restating names. No filler sentences.

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 10-parameter geometry tool with no annotations and an output schema, the description covers the drawing semantics, modes, units, and direction well. It could add the context that a sketch must be active and note that xm/ym and cx/cy are optional alternatives, but nothing essential to invoking it correctly is absent.

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 only 10%, so the description must compensate, and it does: x1/y1/x2/y2 are start and end, xm/ym is a point on the arc between them, cx/cy is the center with the equidistance constraint, and sketch_index 0 means the latest sketch. Only 'instance' is not explained here, but the schema itself documents it.

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 specific verb and resource ('Draw an open arc from (x1, y1) to (x2, y2) in mm') plus a concrete use case (closing a profile drawn with draw_line). It also explicitly distinguishes itself from the sibling draw_closed_profile, so the agent can separate the two without inspecting schemas.

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

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

Gives explicit routing: use this for open arcs, e.g. to close a draw_line profile, and 'For closed shapes prefer draw_closed_profile.' That names the alternative and the condition selecting it, leaving little 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?

With no annotations, the description must carry the full burden; it does disclose two non-obvious behaviors — that a diameter constraint is added automatically and that construction circles are excluded from the profile. It does not state preconditions (must a sketch already exist? does it need an active document/instance?) or what happens with an invalid sketch_index.

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 core purpose is front-loaded in one sentence, followed by a compact Args block. The extra clause on construction mode is short and earns its place by preventing a common misuse.

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 6-param mutation tool with no annotations, the description covers units, coordinate meaning, sketch targeting, construction mode, and the automatic constraint side effect, and an output schema exists to cover returns. The remaining gap is execution prerequisites (sketch/document/instance state), which an agent would still have to discover.

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 only 17% (only 'instance' is documented), so the description must compensate — and it does for five of six params: mm units for x/y/diameter, 'sketch_index 0 = latest sketch', and the construction semantics with a concrete PCD example. Only 'instance' is left to the schema, which already covers it.

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 specific verb ('draw') and resource ('circle in a sketch') plus a defining behavioral trait: an automatic diameter dimension is added. An agent can distinguish it from draw_rectangle, draw_arc, and draw_polygon without inspecting any schema.

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

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

The construction flag carries an explicit use case ('useful for showing bolt PCD without cutting'), which is genuine when-to-use guidance for that option. However there is no guidance on when to prefer this over draw_closed_profile or draw_slot, and no stated prerequisites such as needing an active sketch or connected instance.

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

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

No annotations exist, so the description carries the full burden and does well: it discloses that endpoints are shared to form one closed loop, that rounded corners come from tangent arcs with lines trimmed, and that three-point arcs are immune to sketch axis-direction flips. It does not say what happens on invalid/self-intersecting input or whether an existing sketch is required.

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?

Front-loaded purpose sentence, then a compact format table, then two concrete examples. Every line — including the examples — disambiguates a real encoding decision the agent must make; nothing is filler.

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

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

For a three-parameter geometry tool with an output schema, the description covers units, the full points encoding, sketch targeting, and the closure guarantee. An agent has everything needed to construct a valid call without consulting other 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 coverage is only 33%, and the description compensates thoroughly: it fully specifies the points encoding ([x,y], [x,y,r], {"through":[x,y]}) with worked examples and explains sketch_index semantics ('0 = latest sketch') and mm units. Only 'instance' is left to the schema, which already documents it.

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 specific verb and resource ('Draw a closed profile of lines AND arcs') and immediately differentiates from the many sibling drawing primitives (draw_line, draw_arc, draw_polygon, draw_rectangle) by emphasizing 'closed' and 'segments share their end points'. An agent can tell at a glance this is the right tool for a sealed loop destined for extrude/revolve.

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?

Gives clear usage context ('Inventor sees one closed loop for extrude/revolve') and an explicit prohibition ('Never approximate a curve with many short lines'). It lacks an explicit pointer to when to prefer draw_line/draw_arc or draw_polygon instead, so a small inference remains.

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

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

With no annotations, the description carries the disclosure burden. It does add real domain behavior: coordinates are in mm, sketch_index 0 means the latest sketch, and a construction line becomes a revolve axis and is excluded from the profile. It omits whether the call mutates the open document, requires a transaction, or what happens when no sketch exists.

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

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

Front-loaded one-sentence purpose followed by a compact per-argument list; every line carries information (units, endpoints, index convention, construction semantics) with no filler.

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

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

An output schema exists so return values need not be described, and parameters are mostly covered. However, a mutation tool with zero annotations and 7 parameters should state prerequisites (an active document/part and which sketch is being edited) and whether the geometry is committed immediately, which it does not.

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 only 14% (just the instance param), so the description must compensate and largely does: x1/y1/x2/y2 are labeled start/end in mm, sketch_index is explained as '0 = latest sketch', and construction is explained semantically, not just as a boolean. The instance parameter is left entirely to the schema.

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

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

States a specific verb and resource ('Draw a line in a sketch') plus the unit convention (mm), which makes it clearly distinct from draw_rectangle, draw_circle, draw_arc and draw_polygon. It stops short of explicitly disambiguating against the other sketch-drawing siblings or telling the agent which geometry primitive fits which situation.

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 draw_closed_profile or the other drawing primitives, and no stated precondition such as an active document or an existing sketch. The only contextual hint is the inline note that sketch_index 0 targets the latest sketch, which is parameter trivia rather than usage guidance.

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

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

With no annotations provided, the description carries the full burden and does add useful behavioral context: units are mm, coordinates define the first copy, dx/dy are pitches, pcd/count/start_angle control circular layouts, and slots/rectangles rotate with the circle. It still omits important operational details such as whether the sketch must already exist, which document is affected, and what errors or side effects occur on invalid input.

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

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

The description is compact and well-structured for a 17-parameter tool: a front-loaded purpose statement, separate Grid and Circle explanations, and an Args section for shape-specific semantics. Every section contributes useful information without excessive repetition.

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

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

Given the tool's complexity, 17 parameters, and the presence of an output schema, the description is quite complete: it covers pattern modes and nearly all parameter meanings. It could be stronger by explicitly stating prerequisites, active-document behavior, and how it differs from feature-level patterning siblings.

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 only 6%, so the description must compensate, and it largely does. It explains x/y placement, dx/dy pitch, rows/columns, pcd/count/start_angle for circular patterns, the shape-dependent meanings of diameter/length/width/corner_radius, angle behavior, and sketch_index. The remaining instance parameter is documented in the schema itself.

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

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

The description clearly states that this tool places many copies of one shape in a sketch, with concrete examples such as vent slots, hole grids, and bolt circles. It also distinguishes grid patterns from circular patterns. It does not explicitly differentiate itself from siblings like add_circular_pattern or draw_slot, but the core purpose is clear.

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

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

Usage is implied through examples and the split between Grid and Circle modes, which helps an agent understand intended scenarios. However, the description does not explicitly say when to use this tool instead of draw_slot, draw_rectangle, add_circular_pattern, or other siblings, nor does it list exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses units and sketch targeting, but does not explain whether the sketch must already exist, whether this mutates or creates geometry, what happens on invalid input, or other operational 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 front-loaded and compact: one sentence states the action and units, followed by a clean Args list. There is no unnecessary explanation.

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?

Because there are no annotations and the input schema has low description coverage, the description should do more to explain preconditions and mutation behavior. It adequately covers geometry parameters, but omits sketch-state prerequisites and error/return behavior despite being a drawing mutation tool.

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

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

Schema description coverage is only 17%, but the description compensates well by documenting x/y as center coordinates, radius as circumscribed radius, sides with a hexagon example, and sketch_index where 0 means latest sketch. The one omitted parameter, instance, is already documented in the schema.

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

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

The description states a specific verb and resource — draw a regular polygon in a sketch — and is clearly distinguishable from sibling shape tools such as draw_rectangle, draw_circle, and draw_arc. It also specifies that dimensions are in mm.

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

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

It implies the tool operates on a sketch via sketch_index, but gives no explicit guidance on when to use it versus draw_closed_profile, draw_line, or other sketch tools, nor any prerequisites such as an existing active sketch.

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

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

With no annotations, the description carries the full burden, and it does disclose real geometry behavior beyond the schema: centered placement, millimeter units, and that corner_radius uses real arcs rather than approximations. It says nothing about mutation side effects, undo/transaction semantics, permissions, or failure modes such as a missing sketch — significant gaps for a document-modifying call.

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 one-line front-loaded purpose followed by an Args block is an efficient structure with no filler. Repetition of parameter names in the Args block is justified because the schema gives almost no descriptions to rival it.

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 7 parameters, no annotations, and an output schema the description need not explain, the geometry story is covered well. What is missing is the operational context — whether an active document/sketch is required, what instance selection implies, and what happens on failure — leaving an agent to infer preconditions.

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

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

Schema coverage is only 14%, so the description must compensate, and it largely does: it gives meaning to x/y as center coordinates, assigns mm units to width/height/corner_radius, and explains sketch_index (0 = latest) and corner_radius semantics including the slot case. The seventh parameter, instance, is left to the schema and defaults are not mentioned, but overall meaning is substantially enriched.

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 specific verb and resource — 'Draw a centered rectangle in a sketch' — with the centering convention and unit system (mm) made explicit. The rectangular shape plus the 'corner_radius ... = a slot' note separates it cleanly from draw_slot, draw_polygon, and draw_circle without needing to open their schemas.

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

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

Usage is only implied: 'in a sketch' and 'sketch_index: 0 = latest sketch' hint that a sketch must already exist, and the slot remark hints at when draw_slot is the better choice. There is no explicit when-to-use/when-not statement, no stated prerequisite like an active document, and no named alternative.

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

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

With no annotations, the description carries the full burden; it does disclose units (mm) and that sketch_index=0 means the latest sketch, which is real behavioral context. But it never says the call mutates the active sketch, what happens if no sketch exists, or whether the geometry is added to an existing sketch—material gaps for a write operation with zero annotation coverage.

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

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

The shape definition and anchor are front-loaded in one sentence, followed by a tight per-argument list with no filler. Slightly verbose in restating obvious names, but every line carries meaning.

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

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

Return values are covered by the output schema, so the gap is purely procedural: a 7-parameter sketch-mutating tool with no annotations should say what state must exist (active document/sketch) and what happens on failure. Geometry semantics are complete; operational context is not.

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 only 14% (only 'instance' is documented in-schema), so the description must compensate and largely does: it defines length as end-to-end, width as twice the end radius (a non-obvious constraint that prevents invalid inputs), and angle as direction in sketch coordinates. Only 'instance' is left to the schema.

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

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

States a specific verb and resource (draw a slot) and disambiguates the geometry with two synonyms ('oblong hole / rounded-end profile') plus its anchor point. Against siblings like draw_rectangle, draw_circle, draw_arc and draw_polygon, an agent can pick this one 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?

No statement of when to use this versus draw_rectangle/draw_closed_profile, and no prerequisites such as needing an active sketch or document. Usage is only implied by the parameter list.

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

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

With no annotations, the description carries the full burden. It discloses useful behavior — read-or-write semantics, unknown keys becoming custom properties, and the mass override rationale — but does not clarify whether writes replace or merge existing values, permissions required, or side effects beyond feeding the BOM/title block.

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 front-loaded with the core read/set purpose and property list, then moves into structured Args. It is mostly efficient, though 'manage_materials lists them' is repeated across the material and mass_kg entries.

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?

An output schema exists, so return values need not be explained. The description covers the main call semantics, custom-property behavior, material sourcing, and mass override; the main remaining gap is mutation/overwrite behavior, which matters for a tool with no annotations.

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

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

Schema description coverage is only 25%, so the description must compensate. It provides an example values object, explains that unknown keys become custom properties, specifies material naming and how to list materials, and explains mass_kg override behavior; only 'instance' is left entirely to the schema's own description.

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

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

The description states a specific verb pair ('Read — and optionally set') and resource ('active document's iProperties') and enumerates the properties affected. It does not explicitly distinguish itself from siblings like manage_parameters or manage_documents, but the purpose is unambiguous.

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

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

It gives clear context for use: these properties feed the BOM and drawing title block, and it names manage_materials for listing material names. The mass_kg override is tied to a concrete scenario (surface-only vendor models). It lacks explicit when-not guidance or direct comparison to other property/parameter 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?

With no annotations, the description carries the full burden and does so thoroughly: namespace persistence, per-instance namespaces, SilentOperation, the SaveAs side-effects on dependent/protected/Content Center files, late-binding rules, cancellation grace period, and return of stdout/stderr or traceback with named COM errors.

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

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

Length is justified by tool complexity and it is front-loaded with purpose followed by a structured pre-bound objects list. Dense but nearly every line earns its place; minor cognitive load from the compact multi-item bullet line ('doc — ... comp — ...').

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 powerful code-execution tool with an output schema (so return shape is covered structurally), the description still adds return/error detail, unit gotchas (cm vs mm), and save semantics. An agent has everything needed to call it correctly and safely.

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

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

Schema coverage is only 25% (only `instance` is documented in-schema), and the description compensates well by explaining undo_on_error (rollback of half-built sketches/work planes) and timeout (cancelled() semantics and CANCEL_GRACE). `code` is only described minimally as 'Python source', leaving a small 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?

States a specific verb and resource ('Execute Python code against the live Inventor connection') and the pre-bound object list makes clear this is a general escape-hatch distinct from the many specialized sibling tools (manage_features, extrude, fillet, etc.). An agent can tell exactly what this does versus its 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?

Provides rich operational context (cancellation flow, persistence, helper loading via load_library/startup.py) but never explicitly states when to reach for this over a specialized sibling like extrude or manage_features. Usage is implied by the escape-hatch nature rather than stated as a rule.

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

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

With no annotations, the description carries the disclosure burden and does add useful behavior: the CSV is UTF-8, ';'-separated, and is written as a side effect when path is supplied. It does not say whether an existing file is overwritten, what happens when no assembly is active, or that the operation is otherwise read-only, leaving gaps for a tool with a write side effect.

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?

Front-loaded with what is exported, then purpose, then per-argument notes; no filler sentences. The column list is long but each item is informative, and the args block is compact.

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?

An output schema exists, so return shape need not be explained, and the argument semantics are largely covered. What remains missing for an export tool with no annotations is failure behavior (no active document, bad path) and differentiation from the other export tools, which the description never addresses.

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

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

Schema coverage is only 33%, but the description compensates well by defining both undocumented parameters: view's two modes ('parts_only' flattening with total quantity vs 'structured' indented sub-assemblies) and path's file format and encoding. Only the `instance` parameter's meaning lives solely in the schema, and that is documented there.

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 specific verb and resource ('Bill of materials of the active assembly') and enumerates the exported columns, so the agent knows exactly what comes out. It does not name the sibling export tools (export_document, export_flat_pattern) it must be distinguished from, so it stops short of a 5.

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

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

Gives an intended consumer ('For purchasing / ERP') and a prerequisite ('set part numbers and descriptions first'), which is real usage guidance. However, the prerequisite names 'properties()', a function that does not appear among the siblings (edit_properties does), and no alternative export tool is mentioned for when a full document or flat pattern is wanted.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states the export action and formats but omits overwrite behavior, required document state, permissions, failure modes, and whether the source document is modified.

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 core action is front-loaded in the first sentence, and the Args block is compact. The path example is useful and there is no meaningful waste, though the docstring-style formatting is slightly mechanical.

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?

An output schema exists, so return values need not be explained, and the schema documents the instance parameter. However, for a file-writing export operation with no annotations, missing overwrite and active-document requirements leaves a clear gap.

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

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

Schema coverage is only 33%, but the description compensates by documenting the path purpose with an example and the allowed format values STEP, STL, SAT, and IGES. It omits the instance parameter, though the schema itself describes that parameter adequately.

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

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

The description states a specific verb and resource: export the active document to another format. It is clear enough to distinguish from most siblings, though it does not explicitly contrast with save_document or import_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?

Usage is implied: use this when the active document needs to be written in another format, and the supported formats are listed. It does not explicitly say when to use this versus save_document, nor does it state prerequisites such as having an active document open.

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

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

With no annotations, the description carries the full behavioral burden and does disclose important traits: it creates a flat pattern if none exists, explains the output layers, and notes what is omitted (tangent lines, sketches). However, it does not state whether an existing output file is overwritten, what permissions are required, or how failures are handled.

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 front-loaded with the main purpose and output, then adds layer details and an Args section. It is appropriately sized for an export tool, with no wasted sentences, though the Args section partly repeats information already stated.

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

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

Given an output schema exists, the description need not explain return values, and it sufficiently covers the core export behavior, layer mapping, side effect of creating a flat pattern, and parameter usage. Minor gaps around overwrite behavior and the instance parameter are acceptable because instance is documented in the schema.

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

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

Schema description coverage is only 25%, so the description must compensate, and it does for three of four parameters: path behavior when empty, format as DXF or DWG, and bend_lines controlling bend-line layers. The remaining instance parameter is documented in the schema itself.

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

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

The description states a specific verb and resource: exporting the flat pattern of the active sheet metal part, including flat size, thickness, and bend count. It also specifies the DXF/DWG output and layer mapping, which clearly distinguishes it from sibling export tools such as export_document and export_bom.

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

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

The description gives clear usage context: an empty path reports only the flat size, while providing a path produces a DXF/DWG file. It also explains that a flat pattern is created if the part lacks one. It does not name alternative tools or exclusions, but the conditions for using this tool are clear.

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

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

With no annotations, the description must carry the behavioral burden. It discloses that distance is ignored when extent_type='all' and lists operation modes, but does not state that this mutates the active document, what prerequisites (active document/sketch) are required, whether it is undoable, or what errors occur if no sketch exists.

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

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

The purpose is front-loaded, followed by a compact Args list that adds necessary parameter meaning. There is minor redundancy ('Distance in mm' appears twice) but no wasted sentences.

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 mutation tool with no annotations, the description covers the main parameters and omits return values appropriately because an output schema exists. However, it lacks prerequisite/side-effect context (active sketch/document, undo behavior) needed for safe invocation.

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

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

Schema description coverage is 17%, but the description explains five of six parameters: distance units/condition, direction choices, operation choices, sketch_index semantics, and extent_type values. It omits instance, though the schema itself describes that parameter, so the description largely compensates for the low coverage.

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

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

The description names a specific verb ('Extrude') and resource ('sketch profile') and states the outcome ('create 3D geometry'). It does not distinguish this tool from siblings such as revolve or sweep_rotation, so it is clear but lacks explicit sibling 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?

It explains parameter choices like extent_type='all' and operation options, but gives no explicit when-to-use guidance, prerequisites, or comparison to alternatives such as revolve. The agent must infer that this is the tool for linear extrusion from the purpose statement alone.

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

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

No annotations are provided, so the description carries the full burden, and for a model-mutating operation it discloses little: no statement that it modifies geometry irreversibly, no failure/error behavior, and no mention that it acts on the currently active document unless instance selects otherwise. Only the radius unit is added.

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 core sentence is front-loaded and the args block is compact, with no wasted prose. Minor redundancy in restating radius after the opening line mentions mm, but nothing that costs comprehension.

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

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

With an output schema present, return values need no explanation, and the edge-discovery path is covered. What's missing is the surrounding context for a mutating modeling operation: target body/document selection, preconditions, and what happens when an edge index is invalid.

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

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

Schema coverage is only 33% (only instance is described in the schema), but the description compensates well for the other two: it gives the radius unit in mm and specifies the edge_indices format with an example ('1,2,3') plus a pointer to find_edges for discovering values. This is meaningful added meaning beyond the schema.

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

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

States a specific verb and resource ('Add fillet (rounded edge) to edges of the solid body') with units, and the parenthetical 'rounded edge' implicitly separates it from the sibling chamfer. It stops short of naming chamfer explicitly, so an agent must infer the distinction.

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

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

It routes the agent to find_edges for obtaining edge indices, which is genuinely useful, but says nothing about when to choose fillet over chamfer, or what preconditions must hold (an active document, an existing solid body, edges that can be rounded).

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

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

No annotations, so the description carries the full burden. 'Find' implies a read-only query, and the description discloses filtering semantics and what an empty `path` resolves to. It does not disclose truncation behavior when `max_count` (default 40) is hit, what happens with zero matches, or unit conventions beyond 'mm'.

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 leading sentence is front-loaded with the core behavior and the two-mode split, followed by a compact Args block. The Args list partially restates schema titles but earns its place by adding meaning (circle center, 'skip edges shorter than this', 'most results to return').

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?

An output schema exists, so return values need not be described. For a 7-parameter read tool with no annotations, the definition covers mode selection, filters, and downstream consumers well; the remaining gap is silent truncation via the default `max_count` of 40.

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

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

Schema coverage is only 14%, so the description must compensate, and it does: it documents 6 of 7 parameters including a literal example for `at` ({"X": 50, "Z": 1.5}) and a sample `ref` string for the component path. Only `instance` is left to the schema, and `at`'s freeform anyOf object still lacks a full key list.

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 specific verb and resource ('Find edges') and immediately splits the behavior into two modes keyed on `path`, so the agent understands the two distinct retrieval shapes. It never names `find_faces` or other siblings, so differentiation from the nearest neighbor is only implicit via the word 'edges'.

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?

Gives concrete downstream routing: edges without `path` feed add_flange/fillet/chamfer, circular edges from a component feed constrain(kind="insert"). That is genuine when-to-use guidance, but there are no explicit exclusions (e.g. when to use find_faces or project_edges instead).

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

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

With no annotations, the description carries the burden and largely meets it: results are in TOP assembly coordinates, sub-assembly paths fan out across every part, and the `ref` format is shown verbatim. It omits anything about fan-out cost, ordering, or behavior on zero matches, and never states the read-only nature explicitly (only implied by 'find').

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?

Purpose is front-loaded, then scoping semantics, then a compact Args block — nothing is filler. The middle sentence is a dense run-on that packs path depth, coordinates, ref format and recursion into one line, which costs a little readability.

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?

An output schema exists, so return values need no prose, and all 8 params are covered across schema and description. What is left unstated is how filters combine (AND vs. override) and whether the result is coordinate-rich enough for constrain without a second lookup.

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

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

Schema coverage is only 13%, so the description must compensate, and it does: it documents 7 of 8 params with meaning and concrete examples ([0,0,1] for an upward normal, {"Z": 182.5} for a center match, surface values "plane"/"cylinder"/"cone", empty-string = any). The one remaining param, `instance`, is already described in the schema.

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

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

States a specific verb and resource (find faces) plus the exact filter axes: type, direction, position, size. The path/no-path split makes the scoping model explicit, which is enough for an agent to tell this apart from find_edges and from inspection tools like inspect_model.

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?

Explains the two operating modes (no `path` = active part, `path` = assembly component at any depth) and even names downstream consumers of the returned index/ref (create_sketch, sheet_metal_cut, constrain). It does not name explicit alternatives or say when *not* to use it, but the context for each mode is clear.

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

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

With no annotations, the description carries the behavioral burden and does so well for a status tool: it explains that the execute_python namespace ages and is lost after a server restart or reload_api, and that the tool reports when Inventor is busy or showing a dialog instead of a normal status. It does not explicitly state read-only safety, but 'Check' strongly implies it.

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

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

Two tightly constructed sentences front-load the main purpose and then add the execute_python namespace lifetime and busy-dialog behavior. Every clause contributes useful context without repetition.

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

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

The tool is simple, has an output schema, and the description covers the key status areas and the busy-dialog edge case. The only notable gap is explicit routing guidance versus list_instances and connect, but overall the definition is sufficiently 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 only parameter is fully documented in the schema, including the reference to list_instances for choosing an instance. The description adds no parameter semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Check') and names the exact resources returned: connection status, active document info, and the execute_python namespace. It clearly distinguishes itself from execution or modification tools, though it does not explicitly separate itself from list_instances or connect.

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?

Usage is implied by the diagnostic nature of the tool, but the description does not state when to call get_status instead of list_instances or connect. It mentions reload_api only as a cause of namespace loss, not as an alternative tool-selection condition.

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

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

With no annotations, the description carries the full burden and does well: it discloses a real filesystem side effect (the STEP is copied into dest_folder) and explains why (Inventor writes assembly parts next to the .step file), which is non-obvious behavior an agent could not infer. It also summarizes the return payload. It does not state what happens on name collisions or whether existing files get overwritten, which is the remaining gap for a file-creating mutation.

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?

Front-loaded with the core action, then the rationale for the copy, then the downstream use of the return values, then a clean Args block. Every sentence carries information; the only mild redundancy is restating name's default in the Args block, which the schema title already implies.

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 4-parameter mutation with an output schema already documenting return structure, this description covers action, side effects, rationale, output summary, and downstream handoff. Nothing an agent needs in order to call it correctly and use the result is missing.

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

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

Schema coverage is only 25%, so the description must compensate, and it largely does: an Args block documents step_path, dest_folder, and the name default (STEP file name). The fourth parameter, instance, is omitted from the description but is the one parameter the schema itself documents (pointing at list_instances), so coverage is effectively complete.

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 specific verb and resource: import a vendor STEP file and produce Inventor files in a destination folder. It is clearly distinguishable from siblings like load_library (library parts), place_components (assembly placement), and create_document (empty docs). The parenthetical examples of vendor parts add a concrete sense of scope.

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

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

Explicitly routes the agent forward: use the returned bbox data to find mounting faces and axes *before* placing with place_components, which names the sibling and the ordering constraint. There are no explicit when-not-to-use conditions or prerequisites (e.g. Inventor connectivity, licensing), so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden, and it does real work: it discloses that the snapshot includes warnings about faceted curves and surface bodies, which tells the agent to expect degraded-geometry signals. It never explicitly states the operation is read-only or says anything about cost on large assemblies, which keeps it out of 5 territory.

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 tight sentences, front-loaded with the core value proposition, then a dense enumeration split cleanly by Part versus Assembly. Every clause carries information; nothing is filler.

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

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

An output schema exists, so the description needn't explain return values, yet the Part/Assembly enumeration is genuinely useful for tool selection across a 50+ sibling surface. What's missing is any note on scope limits (e.g., whether it works with no active document) or performance on large models.

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 one parameter and schema description coverage is 100%, so the schema already explains instance and points at list_instances. The description adds nothing about the instance argument, so the baseline 3 applies.

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

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

Specific verb+resource ('snapshot of the active document') with an explicit inventory of what is included for both Part and Assembly cases, which lets an agent tell it apart from targeted queries like find_faces or measure_distance. It stops short of naming any sibling explicitly, so it lands at 4 rather than 5.

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

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

The phrase 'in one call' implies this is the broad-orientation tool versus the many narrow query tools, but the description never states when to prefer it or when to reach for find_faces/get_status instead. Usage is implied rather than instructed.

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

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

With no annotations, the description carries the burden and discloses useful behavior: it returns instances even when they are busy, and it includes manually opened Inventors the server cannot reach. It does not explicitly state safety or error behavior, but the read-only nature is strongly implied by listing instances.

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

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

Two sentences, front-loaded with the resource and supplemented by the key busy/unreachable behavior. There is no wasted text.

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

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

For a zero-parameter list tool with an output schema, the description is nearly complete: it explains scope and the busy-instance behavior. It could improve by explicitly naming when to choose it over sibling discovery tools.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly adds no parameter detail because there are none.

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

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

The description clearly identifies the resource: Inventor application instances connected to the server, including manually opened ones it cannot reach. It distinguishes this from document-focused siblings like list_documents, though it never uses an explicit verb such as "list".

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?

Usage is implied: an agent would call this to discover connected or unreachable Inventor instances. However, it gives no explicit when-to-use guidance or named alternatives among siblings such as status or list_documents.

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

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

With no annotations, the description carries the burden and does well: it discloses persistence semantics (remembered per project, reloaded after reload_api, new namespace, or new server), timing feedback, and a global startup hook. It omits error behavior for a bad path and whether a re-load of the same path replaces or appends to the namespace.

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?

Front-loaded with the core action and persistence contract, then supporting detail about timing and startup. The pacing sentence ('Says how long it took…') is slightly conversational but still carries diagnostic 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?

Output schema exists, so return values need not be explained. For a stateful mutation with no annotations, the description covers persistence, lifecycle, and side effects well; only path validation and namespace-collision behavior are missing.

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

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

Schema coverage is only 50% and the undocumented parameter is the required one — 'path'. The description never says whether it must be absolute, must exist, or what happens on a bad path; it only incidentally mentions a startup file location. The optional `instance` parameter is documented in the schema, so the description adds nothing there.

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 specific verb and resource ('Run a Python file into this Inventor's execute_python namespace') plus the key distinction that it persists, which separates it from execute_python and reload_api. An agent can identify the tool's job 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?

'For helper functions you would otherwise redefine every time' gives an explicit use case, and the reload_api/new-server survival notes clarify when persistence matters. It never explicitly names execute_python as the alternative for one-off code, so the exclusion side is only implied.

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

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

With no annotations, the description carries the full burden and does it unusually well: it discloses the 45 s wait cap and early return, the 2 s cancel grace window, repeated KeyboardInterrupts, and the important limitation that a call stuck inside one COM operation or behind a dialog only stops once that returns. It omits post-cancel state (does status still report a cancelled call, is partially-applied Inventor work rolled back?), which is the remaining behavioral gap.

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

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

The structure is front-loaded — purpose, then per-action behavior, then args — and nearly every sentence adds behavioral information rather than restating schema. The Args block is justified because the schema lacks descriptions for action and wait_seconds, but the formatting (stray quotes, terse arg notes) is slightly ragged and the ending trails off.

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, zero-annotation tool with an output schema present, the description covers what an agent needs: when to poll, how long to wait, how cancellation actually behaves and where it fails to take effect. Return contents are sketched (elapsed time, dialog text, output so far, progress() line) even though the output schema would have sufficed.

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

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

Schema coverage is only 33% (only 'instance' is documented), so the description must compensate — and it largely does by enumerating the action's valid values ('status' or 'cancel'), which the schema leaves as an undescribed free string, and by tying wait_seconds to the status action with a 45 s cap. It never explains the wait_seconds=0 default or the omitted-action default, so it does not fully close the 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 first sentence states a specific pair of verbs (follow/poll or stop) against a specific resource (a long-running call), and disambiguates from execute_python by identifying this as the follow-up tool for calls that outlived their wait. The examples (long execute_python, Content Center scan, Inventor dialog) make the target scenario unmistakable.

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

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

It clearly establishes the trigger condition — use this only after a call has outlived its wait — and routes between the two modes by explaining what each action does. It stops short of explicit exclusions, e.g. it never says how this differs from get_status or whether it applies to calls other than execute_python/Content Center scans.

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

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

No annotations are provided, so the description carries the full burden. It reveals the dual read/destructive-mode design, but says nothing about deletion being irreversible, whether it requires confirmation permissions, what happens to dependent features, or what an invalid index does. For a tool whose 'delete' path mutates the model, this 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 elements: a one-line purpose sentence followed by a compact Args block. Front-loaded, no filler, and every line carries information about behavior or parameters.

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?

An output schema exists, so return values are covered elsewhere, and all three parameters get some explanation. But for a tool with a destructive branch and zero annotations, the absence of any warning about irreversible deletion or index validity leaves a meaningful hole for safe invocation.

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

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

Schema coverage is only 33% (only 'instance' is documented in the schema), but the description compensates by enumerating the accepted values of 'action' ("list" or "delete") and explaining that 'index' is a constraint index obtained from list. That covers the two undocumented parameters meaningfully, though defaults (action='list', index=0) go unmentioned.

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

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

The description names a specific verb pair and resource: 'List the active assembly's constraints, or delete one.' That tells an agent exactly what the tool operates on. It does not explicitly distinguish itself from the sibling 'constrain' (presumably constraint creation), leaving the create-vs-manage split to inference.

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 'list' then 'index from list' sequencing implies the correct two-step workflow for deletion, which is useful guidance. However, there is no statement about when to use this versus 'constrain', no prerequisites, and no note that delete is only meaningful with an index obtained from a prior list.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses protected-file handling, unsaved-change refusal behavior, discard=True overrides, and quit_inventor side effects. These are meaningful behavioral traits beyond the schema, especially for destructive close/quit actions.

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 action-by-action structure is efficient and front-loads the core document operations, with an Args section that maps cleanly to parameters. The opening line 'Open documents of this Inventor' undersells the full manage/close scope, but otherwise the text is compact for a six-parameter, six-action tool.

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

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

Given six parameters, no annotations, low schema coverage, and an output schema, the description is largely complete for correct invocation: it covers action semantics and destructive behavior well. The main remaining gap is that it does not explicitly route the agent away from related sibling tools such as create_document or save_document.

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 only 17%, so the description must compensate. It documents action values, name_or_path usage, include_active, discard, and quit_inventor, adding essential semantics that the schema does not provide, especially the otherwise unconstrained action string.

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

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

The description clearly identifies document lifecycle operations for the connected Inventor and enumerates specific actions: list, open, activate, close, close_unsaved, and close_all. It is clear what the tool does, but it does not explicitly distinguish itself from related siblings such as create_document, save_document, or export_document.

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

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

It gives clear per-action context, including when close_unsaved applies to never-saved documents and when close_all refuses due to unsaved changes. It does not explicitly name alternative sibling tools or state when not to use this tool, so it lacks the routing guidance needed for a 5.

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

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

With no annotations at all, the description carries the full burden, and it does disclose two useful traits: the operation targets the active part, and indices must be harvested from a prior list. It does not state that delete is destructive/irreversible, what happens to suppressed features in downstream rebuilds, or whether an active document is required.

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?

Front-loaded single sentence followed by a compact per-argument block; every line earns its place. The framing of prose-and-Args-duplicating-schema is slightly wasteful but not confusing.

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?

An output schema exists, so return values needn't be explained, but a destructive-capable mutation tool with zero annotations should still disclose reversibility and preconditions. The description covers two of three parameters and the basic workflow but leaves the risk profile of delete and suppress unstated.

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

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

Schema coverage is only 33%, with just the instance parameter documented in the schema, so the description must compensate — and it does, giving the action vocabulary and the comma-separated indices format with a concrete example ("3,4,5"). It still doesn't say what index domain list returns or whether indices are stable across edits.

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 specific verb set (list/delete/suppress) and a specific resource (the active part's features), which is distinguishable from siblings like manage_parameters, manage_constraints, and manage_occurrences. It never explicitly names those siblings as alternatives, so it stops short of a 5.

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

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

The Args block enumerates the valid actions and states that indices come from a prior list call, which implies the list-then-mutate workflow. However, there is no guidance on when to choose this tool over manage_parameters/manage_occurrences, and no stated preconditions such as requiring an open part document.

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

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

With no annotations, the description carries the full load and does substantial work: it discloses that 'set' is a mutation that must be saved afterwards, that Content Center/library parts are skipped, and what 'report' flags (Generic material, surface-only vendor models, missing mass). It stops short of stating failure behavior for bad material names or partial-application semantics.

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

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

Structure is sensible: a short framing, per-action semantics, then an Args block that mostly adds examples rather than restating types. A few lines (the bare opening fragment) are thinner than they need to be, but there is little waste for an 8-parameter tool.

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

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

Given eight parameters, no annotations, and an output schema that covers return shape, the description supplies the behavioral context an agent needs: what each action does, exclusions, and the save side effect. Remaining gaps (error handling, partial-failure behavior) are minor.

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

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

Schema coverage is only 13%, so the description must compensate, and it largely does: it describes action values, `material` format with an example, `search` purpose, comma-separated `parts` patterns with an example, and the meaning of `only_generic`, `path`, and `only_problems`. The `instance` param is left to the schema (where it is documented), which is the only 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 opening fragment is weak, but the per-action breakdown (report/list/set) makes clear this is a material management tool spanning inspection and assignment across many parts. It differentiates its three modes cleanly, though it never contrasts itself with sibling tools like edit_properties that might also touch materials.

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?

Each action carries implied selection criteria: 'report' to audit, 'list' to discover library names (with `search` narrowing), 'set' to assign. It also notes exclusions for 'set' (Content Center and library parts are left alone) and the need to save afterwards. No explicit when-not-to-use against a sibling, keeping it below a 5.

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

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

With no annotations present, the description carries the behavioral burden and discloses important side effects: delete first reports dependencies and stops unless force=True, cascade=True also deletes pattern members, and ground with grounded=False releases a component. It does not cover permissions or all possible state changes, but it provides meaningful behavioral context for the main mutations.

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

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

The description is compact and front-loads the core resource, then groups behavior by action before listing arguments. It avoids wasted prose, though the formatting is somewhat fragmentary and could be more clearly sectioned.

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 complex 11-parameter tool with no annotations and low schema coverage. The description covers action semantics and most parameter meanings, but it lacks usage guidance versus sibling tools and omits some operational context, such as how instance selection interacts with the actions. The output schema reduces the need to explain return values.

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 very low at 9%, so the description must compensate. It does define most parameters by action, including path, depth, definition pattern, axis direction, near point, within distance, grounded, cascade, and force, though some definitions are terse and the instance parameter is only described in the schema.

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

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

The description states that this tool deals with components of the active assembly and enumerates specific actions: list, find, ground, and delete. This is a clear verb-and-resource statement, though it does not explicitly distinguish itself from siblings such as place_components or manage_constraints.

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

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

The description explains what each action does and gives some operational hints, such as grounding the first component and how delete initially stops on dependencies. However, it does not state when to choose this tool over alternatives or provide explicit exclusions 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?

With no annotations, the description carries the full burden. It does disclose the 'active document' scope and that 'get' returns all parameters, which is useful mutation context. But it does not say what happens if 'set' targets a nonexistent name, whether 'add' overwrites duplicates, or whether changes are undoable via the transaction sibling.

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?

Front-loaded summary sentence followed by a tight Args list; nothing is padded or redundant. The docstring formatting is slightly mechanical but each line carries real information for a consumer.

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?

An output schema exists, so return values need not be explained. For a five-parameter mutation tool with zero annotations, though, the description should say more about failure modes, persistence, and interaction with the transaction tool. As written it is adequate but leaves the agent guessing on error behavior.

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

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

Schema coverage is only 20% (only 'instance' is documented structurally), so the description must compensate, and it largely does: it explains action values, gives examples for name ("width") and expression ("50 mm", "width * 2"), and restricts units to add with examples (mm, cm, m, deg). The only gap is that 'instance' is not mentioned in the description, though the schema covers it.

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

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

Description starts with a concrete verb triple and resource: "Read, change or add parameters of the active document." An agent immediately knows the operation and the target object, and 'parameters' is distinct from siblings like manage_features or manage_constraints. It lacks explicit differentiation from those siblings, keeping it below a 5.

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

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

The Args block enumerates action values "get" (all), "set", "add", which implies the modes of use and hints that 'get' returns all parameters. However, there is no guidance on when to prefer this tool over inspect_model or manage_features, no prerequisites (e.g. a document must be open), and no exclusion conditions.

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