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

No annotations are provided, so the description carries the full burden. It discloses the precondition (document must be open) and the state change (it becomes the active one), but says nothing about failure modes, ambiguity resolution, or whether the switch affects subsequent tool calls — significant gaps for a state-mutating tool with zero annotation coverage.

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

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

A single front-loaded sentence that states the effect first and the accepted input forms parenthetically. No filler, nothing redundant with the title or schema.

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

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

An output schema exists so return values need no explanation, but the tool mutates application state with no annotations and only one sentence of prose. An agent cannot tell what happens when the name is ambiguous, when the document is not open, or how this interacts with the 'instance' parameter.

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

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

Schema coverage is 50%: 'instance' is documented in the schema, while 'name_or_path' has no schema description. The description partially compensates by explaining that the identifier can be a display name or a full path, which is genuine added meaning, but the instance parameter is never mentioned in the description.

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

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

Specific verb ('Make ... active') on a specific resource ('an open document'), with the accepted identifier forms named. It is clear what the tool does, though it does not explicitly contrast itself with siblings like list_documents or save_document that also deal with open documents.

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 word 'open' implies the precondition that the document must already be loaded, so usage is inferable. There is no explicit when-to-use/when-not guidance, no mention of using list_documents to discover valid names, and nothing about behavior when several documents match.

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 does not say whether the name must be unique, what happens on collision, whether an active document is required, or whether the new parameter triggers a model rebuild.

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?

Short and front-loaded, with the purpose stated first and per-argument notes after. The stray quoting/blank line after the args block is cosmetic waste but nothing substantive is bloated.

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 most parameters are covered. However, for a mutation tool with zero annotations it omits prerequisites (active document, instance selection) and failure modes, which an agent needs to call it correctly.

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

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

Schema description coverage is only 25% (just instance), but the description compensates by explaining name, expression, and units with concrete examples like "width * 2" and unit values. The instance parameter is documented in the schema itself, so nearly all parameters carry meaning.

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

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

"Add a new user parameter" gives a specific verb plus resource and is clearly distinguishable from set_parameter/get_parameters in the sibling list. It does not explicitly name those siblings, 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?

No when-to-use guidance, no prerequisites (e.g. an active document or connected Inventor instance), and no explicit contrast with set_parameter for modifying an existing parameter. Only the word "new" hints at create-vs-update.

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 disclose the two traits that matter most operationally: the search spans sub-assemblies and results are returned in TOP assembly coordinates in millimetres. It also pins the returned ref format, which is what makes the tool chainable. It does not state that the operation is read-only or address multi-instance selection, which stays implicit.

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 in the first sentence, followed by a compact args block where each line carries concrete, non-redundant information (examples and units rather than restating schema titles). Slightly dense but 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 read-style query tool with a 8-param schema, no annotations, and an output schema already present, the description supplies the missing essentials: coordinate frame, units, ref format, and the origin of the path argument. Remaining gaps are minor (instance selection, ordering/limit interplay) and partly covered by structured fields.

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 13%, so the description must compensate, and it largely does: it gives concrete examples for path ('Z AXIS:1/FIXED PLATE:1'), normal ([0, 0, 1] for faces looking up), at ({"Z": 182.5}), plus units for diameter and semantics for min_area and max_count, and enumerates surface values. Only the instance parameter is left undocumented in the text (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?

Opens with a specific verb and resource ('Find faces of a component') and narrows scope precisely: whole assembly including sub-assemblies, results in TOP assembly coordinates in mm. That scoping clause implicitly separates it from the component-scoped siblings like list_faces and find_face, but it never names them, so the differentiation is inferential rather than explicit.

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

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

It says where the required path comes from ('Component path from list_occurrences(depth=2)') and what to do with results ('Each result has a ref ... that constrain_faces takes'), which is real routing guidance to two sibling tools. It also clarifies sub-assembly recursion. No explicit when-not-to-use or alternative-selection rule is given, 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?

No annotations are supplied, so the description carries the full burden. 'Snapshot' signals a read-only, non-mutating operation and the field list describes what is retrieved, but it is silent on cost, behavior with no active assembly, and whether the snapshot is live or cached.

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

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

Two short sentences with zero filler, and the payload enumeration is front-loaded so an agent can match it against its information need immediately.

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 format need not be explained, and the description still summarizes the returned fields. For a read-only single-parameter aggregate tool this is nearly sufficient; only the no-active-assembly edge case is 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 100%, so the single optional 'instance' parameter is already fully documented in the schema, including the list_instances pointer. The description adds nothing about parameter behavior, so 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?

States a specific verb+resource (snapshot of the active assembly) and enumerates the payload: components with positions, constraint count, mass and volume. It distinguishes itself implicitly from single-query siblings like list_occurrences or list_constraints, but never names 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?

'One call instead of several queries' implies the tool is the aggregate shortcut when you need the whole assembly picture rather than one specific datum. No explicit when-to-use/when-not, no named alternatives, and no prerequisite stated (e.g. that a document must be active).

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 load and does disclose a real side effect — passing path writes a semicolon-separated UTF-8 CSV file to disk. It also implies the operation targets the active assembly, but says nothing about error behavior when no assembly is open or whether generation itself is read-only.

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

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

Front-loaded with the resource and returned columns, then a single-sentence usage note, then a compact per-argument block. Every sentence adds information; nothing is repeated from the schema.

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

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

An output schema exists, so return values need no explanation, and all three parameters are accounted for between description and schema. The main remaining gap is the absence of any note on preconditions (an active assembly must exist) for a tool that writes an external file.

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: it defines both view modes ('parts_only' = every part once with total quantity vs 'structured' = indented sub-assemblies) and explains that path triggers a CSV write with UTF-8 and ';' separators. 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 resource (bill of materials of the active assembly) and enumerates the exact columns produced (item, quantity, part number, material, mass, file). No sibling tool overlaps, so an agent can identify it immediately.

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 a concrete use case ('For purchasing / ERP') and a prerequisite that routes to a sibling: 'set part numbers and descriptions first with properties()'. It does not state when not to use it or what happens if no assembly is active, so it stops short of full when/when-not 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 does useful work by saying the tool is safe to call at any time and by describing what it observes. It also discloses the 45-second wait cap, which is important behavioral context. It does not, however, fully clarify side effects or blocking semantics for every wait scenario.

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 reasonably efficient: it first explains what the tool reports, then documents the key wait parameter. The `Args` section is useful, but the self-referential 'calling call_status again and again' phrasing and the nonexistent `name` reference add avoidable ambiguity.

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

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

The description covers the core monitoring behavior, safety, wait limit, and progress/result reporting, which is enough for an agent to use the tool. Because an output schema exists, it need not describe return values in detail, but the missing targeting semantics for a specific call and the `name` inconsistency leave a notable 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?

The schema documents `instance`, and the description adds detailed meaning for `wait_seconds`, including the 45-second maximum and its polling-replacement behavior. However, the description refers to waiting without a `name`, but the schema has no `name` parameter, which creates confusion about how to target a specific call.

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 follows an already-running call and reports elapsed time, dialog text, progress/output, and final result. It is specific about the resource and the observable outputs, but it does not explicitly distinguish itself from the sibling `status` tool or other call-related tools.

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

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

It gives a clear use case: a call that outlived the wait, such as a long job or one blocked behind an Inventor dialog. It also explains that `wait_seconds` can be used instead of polling repeatedly, though it does not explicitly state when not to use this tool or name an alternative sibling tool.

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

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

With no annotations, the description carries the full burden and does so thoroughly: cancelled() flips immediately, a CANCEL_GRACE timeout triggers KeyboardInterrupt in the Inventor thread, the interrupt lands at the next Python line, and calls stuck inside a COM call or modal dialog only stop after that call returns. This is exactly the behavioral nuance an agent needs to set expectations.

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 clause, and every sentence conveys necessary cancellation semantics. The prose is dense and semicolon-heavy, making it slightly harder to scan than it could be, 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?

For a behaviorally complex cancellation tool with no annotations, the description covers mechanism, grace period, thread behavior, and COM-call limitations. An output schema exists, so return values need not be explained; nothing critical 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 description coverage is 100%, so the single 'instance' parameter is already documented in the schema. The description adds no syntax or selection guidance beyond what the schema provides, making the baseline 3 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?

States a specific verb and resource — 'Stop the running call' — and gives concrete examples (long execute_python loop, Content Center scan, wrong job). This clearly distinguishes it from siblings like call_status and execute_python without needing to open either 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 use cases make it obvious when to invoke cancellation: long-running loops, scans, or erroneous jobs. It even advises polling cancelled() in long loops. However, it never names call_status as the alternative for checking progress, nor states when not to cancel.

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?

No annotations are present, so the description carries the burden, and it does disclose important behavioral traits: interferences from touching faces are suppressed (false negatives) and intended overlaps like gasket compression appear (false positives), plus how to disambiguate via volume/bbox. It stops short of stating whether the call is read-only or has any side effects or cost on large assemblies.

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 purpose and the key caveats, then a tight Args block with examples. Slightly verbose in prose but every sentence (touching faces, gasket compression) carries information an agent would otherwise get wrong.

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 geometry query with an output schema and no annotations, the description covers purpose, caveats, set semantics, and even result interpretation. Missing only an explicit note that it is a non-mutating query and whether an active/connected assembly is required.

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-schema), but the description fully compensates for the other two: it gives concrete syntax and an example for set_a, explains the sub-assembly path form ('Asm:1/2'), and defines set_b's empty-value semantics. The remaining parameter is already covered by 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 ('Check overlap between occurrences of the active assembly') and is clearly distinguishable from siblings like measure_distance or assembly_faces. It even scopes the semantics (touching faces excluded, intended overlaps reported), so an agent knows exactly what the result means 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?

Explains the empty-set_b case ('empty = everything else') and how to interpret output ('read the volume and bbox'), which implies usage, but gives no explicit when-to-use-this-vs-alternative guidance or prerequisites (e.g., an active assembly/document must be loaded).

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 behavioral burden. It discloses useful mechanics such as count including the original and angle representing total span, but it does not state that this mutates the document, whether it needs an active document/transaction, 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 purpose and ideal use case are front-loaded, followed by a compact Args list. Every line adds practical information without redundancy.

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

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

The description is complete enough for a CAD patterning operation: it explains the main parameters, the default axis, and the intended workflow. The main remaining gap is operational context around document state, transaction behavior, and mutation side effects, but the output schema covers 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 coverage is only 20%, but the description compensates well: feature_index points to list_features(), count is explicitly total including the original, angle is total span with 360 meaning full circle, and axis defaults to Z for flanges. The only undocumented parameter is instance, which the schema itself explains.

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: create a circular pattern of a feature around an axis. It clarifies the operation enough to distinguish it from generic feature creation, but it does not explicitly differentiate it from nearby siblings like sketch_pattern or hole_linear.

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 flange/bolt-hole example gives a clear, concrete use case and implicitly tells the agent when this tool is preferable to repeating a feature manually. It does not name alternatives or state 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that documents are closed without saving and that referenced documents are preserved, but it does not mention whether unsaved documents are irreversibly lost, whether confirmation is required, or what happens if closing fails.

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 behavior before the Args section. The examples of unsaved documents and the include_active explanation are useful, with little 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 two-parameter tool with an output schema and no annotations, the description covers the main behavior, the preservation rule, and the non-schema-documented include_active parameter. The instance parameter is handled by the schema, and return values are covered by the output 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 coverage is 50%: the instance parameter is documented in the schema, while include_active has no schema description. The description compensates for that gap by explaining include_active, but it does not add anything about the instance parameter beyond what the schema already says.

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: close documents that were never saved, without saving. It also clarifies an important exception, namely that documents referenced by another open document are kept, which makes the tool's scope more precise than the name alone.

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

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

The description implies a cleanup use case through the phrase 'left by failed attempts' and explains when to set include_active. However, it does not explicitly compare this tool with alternatives such as save_document, list_documents, or activate_document, nor does it state when not to use it.

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

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

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?

Without annotations, the description carries full behavioral disclosure. It mentions that origin constraints survive part edits (a durability trait) but omits key mutation details: permissions required, whether the operation is reversible, what happens on constraint conflict, or whether the assembly is modified in place. This is insufficient for a mutation tool with zero annotation coverage.

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

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

The description is front-loaded with the main purpose and then lists arguments in a clear, structured format. The first sentence efficiently conveys the core value proposition, and the bullet list is easy to scan. No unnecessary fluff, though the first sentence is slightly verbose.

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

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

Given the complexity (8 parameters, assembly operation) and the presence of an output schema, the description covers the essential information for calling the tool: purpose, parameter meanings, and allowed values. It lacks some behavioral details like failure modes or prerequisites, but these are partly mitigated by the output schema and inferred context.

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

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

Schema description coverage is only 13% (only 'instance' has a description). The description compensates by explaining most parameters: occurrence indices with a pointer to list_occurrences, allowed values for geometry1/geometry2, semantics of kind (mate/flush/angle), and units for offset and angle. Only 'instance' (covered in schema) lacks additional detail.

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 (constrain) and resource (two components by ORIGIN geometry), and explicitly differentiates from face-based constraints by explaining why origin constraints are more robust. An agent can immediately tell this is for origin geometry, not face picks.

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

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

The description provides clear context for when to use this tool (origin constraints survive edits) but does not explicitly name alternatives or when-not-to-use conditions. The contrast with face picks is implied but not framed as an explicit 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 burden, and it does disclose a real surprise: the call reports which OTHER components moved, since a constraint can drag unintended parts. It also discloses target-document behavior (constraint goes into the active top assembly, sub-assembly refs legal) and the offset-sign retry heuristic. It stops short of saying whether over-constrained or failed solves raise errors, 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 operation and scope, then a side-effect note, then a tidy Args block — nothing is buried. The sentence fragment 'Says which OTHER components the constraint moved' is slightly clipped and the sign caveat is repeated in both the offset arg and a_at, costing a little tightness.

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 mutation tool with no annotations, the description covers the parts that matter: what is being constrained, reference syntax, mode semantics, offset/angle units, sign-failure recovery, output side effects, and which document is modified. An output schema exists, so not spelling out the return payload is not a gap, and the only omission is the optional 'instance' selection parameter.

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

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

Schema coverage is only 14%, so the description must compensate and largely does: it defines a vs b roles, enumerates kind's three values with meaning for each, and scopes offset to mm for mate/flush and angle to degrees for kind='angle'. It leaves the 'instance' parameter undiscussed and does not constrain the keys allowed inside a_at beyond the single 'Z' example.

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 by faces'), names where the refs come from (assembly_faces), and gives literal ref formats so it is unmistakably distinct from generic constrain and constrain_insert. It also pins the scope: the constraint lands in the active top assembly.

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 invocation conditions: which ref forms are accepted, that a is the one meant to move, when to supply a_at ('its sign is easy to get wrong — give a_at too'), and that a_at mismatch triggers a sign retry. It never explicitly says when to prefer constrain_insert or plain constrain over this tool, so it falls short of full alternative-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 must carry the behavioral burden. It usefully discloses the compound effect (aligns axes AND seats faces) and the offset units, but says nothing about whether an existing constraint is replaced, what errors occur on invalid edges, or whether the operation is transactional.

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 behavior is stated in the first sentence before the arg list, and every subsequent line maps to a distinct parameter 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 needn't be explained, and the parameter documentation is thorough for a 7-param tool. The remaining gap is the lack of any failure-mode or precondition disclosure for a mutation call 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 14% (just 'instance'), and the description compensates well: it explains occurrence/edge pairs, cross-references list_component_edges for edge indices, gives offset units (mm) and the semantics of axes_opposed for the normal bolt case. Only 'instance' semantics and the occurrence index basis are 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 (insert constraint between two circular edges) plus the concrete physical case it models (bolt into hole). The 'circular edges' scope implicitly separates it from constrain_faces and generic constrain, though no sibling is named 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?

Gives a clear usage context ('a bolt into a hole in one call') and points the agent at list_component_edges to obtain valid edge indices. No explicit when-not-use guidance or named alternative, which keeps it 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 burden and does so well: it discloses that calls are cheap but the full tree is slow, that length>0 creates a custom member that is saved to disk with a default path, and that length=0 yields a standard member. It does not describe error behavior for invalid paths or whether an existing file is overwritten.

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 example ladder that conveys the recursion better than prose, then terse arg notes. Every line adds information; 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 recursive browse-and-materialize tool with an output schema present, the description covers the traversal model, the file side effect, and downstream consumption. The only omission is the 'instance' parameter, which the schema already documents.

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, and it does for five of six parameters: category path syntax ('/'-separated), family, size (spaces and case ignored), length in mm with 0 = standard member, and file_name with its default template. Only 'instance' is left 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?

States a specific verb and resource (browse the Content Center) and the concrete output (a part file path usable by place_component / place_many). This distinguishes it from the many geometry/assembly siblings without needing to open the schema.

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

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

The step-by-step ladder shows exactly how to drill from top categories down to a sized member, and notes the whole tree takes minutes so a path should be supplied. It clearly hands off to place_component/place_many downstream, though it doesn't state when to prefer other sources (e.g. frame_members, import_step) 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?

No annotations are supplied, so the description carries the full burden. It does disclose one meaningful trait beyond the name — the round propagates into the flat pattern — but says nothing about prerequisites (active sheet metal part, rule resolution), whether the radius is clamped by thickness, or whether the feature is editable/deletable afterwards.

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 followed by a compact Args block; nothing is padded. The parenthetical '(Corner Round — carried into the flat pattern)' is slightly awkward but earns its place by flagging flat-pattern propagation.

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, but for a geometry-mutating sheet metal tool with no annotations the description omits document/document-state prerequisites and the relationship to the edge-listing tool used to supply indices. Adequate to invoke, thin on context.

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

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

Schema coverage is only 33%, and the description compensates well: it defines edge_indices as comma-separated indices of the short edges through the thickness at the corners, and gives units (mm) for radius. It stops short of five because it does not say how to obtain those indices (list_edges) or what happens when edge_indices is invalid.

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 domain object ('Round sharp sheet metal corners') and adds the important scope note that the round is carried into the flat pattern. It is clear what the tool produces, but it never contrasts itself with the nearby fillet/chamfer siblings, which an agent could plausibly confuse it with.

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?

'Use on exposed corners people handle, e.g. mounting plate tabs' gives a concrete selection criterion rather than leaving usage implied. There is no explicit when-not guidance and no named alternative (e.g. use fillet/chamfer for non-sheet-metal edges), which keeps it 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 full behavioral burden. It mentions creation and template selection, but does not disclose whether a connected Inventor instance is required, whether the new document is activated, how it is saved, or what happens if the name conflicts.

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 definition is short and front-loaded, with the core action in the first sentence and parameter details immediately after. There is very little 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 simple creation tool with an output schema, the description is mostly complete. It explains the document type and template options, but it leaves connection/instance context and document lifecycle behavior to 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?

The schema describes the instance parameter, while the description adds useful meaning for the other two: name is optional and template can be metric, english, or a full .iam path. This compensates well for the low schema description coverage, though instance behavior 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?

The description states a specific verb and resource: create a new empty assembly document (.iam). It is easy to distinguish from create_part and other assembly tools because it explicitly says assembly and empty.

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 clear purpose, but the description does not explicitly say when to use this instead of create_part, place_component, or other document-creation tools. Template guidance is present, but no alternatives or exclusions are named.

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

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

No annotations are supplied, so the description carries the full burden. It conveys that the result is an 'empty' document and that material/part number should be set at creation, but says nothing about where the document is written, whether it is saved, or what happens on failure.

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 Args block; the rationale about BOM/mass earns its place by explaining why to pass metadata. Minor redundancy in listing both part_number and description on one 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, and most parameters are covered. However, for a mutating creation tool with zero annotations, the description omits connection prerequisites and document persistence 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 17% (just 'instance'), and the description compensates well: it explains template values ('metric' mm default, 'english' inches, or a full .ipt path), gives a material example ('Steel, Mild'), and explains that part_number/description are BOM iProperties. Only name is left thin ('Display name').

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

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

States a specific verb and resource: 'Create a new empty part document', and extends it to material and part-number iProperties. It is clearly not a sketch/feature/assembly creation tool, though it never explicitly contrasts with create_assembly or create_sketch.

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?

Implies when to use it via the rationale about avoiding 'Generic' BOM entries, and points to list_materials for material sourcing. It gives no explicit when-not guidance or prerequisites (e.g. must a document/connection be active first).

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

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

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 full burden and does well: it discloses the coordinate system, the silent-no-op failure mode of work-plane cuts, and that the tool post-verifies that material was actually removed. It does not mention permissions, instance requirements, or whether the cut is undoable, 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?

The key differentiator (world coordinates) and the key hazard (silent no-op) are front-loaded in the first two sentences, and the Args block is tight. The example JSON strings are long, but they earn their space for a string-typed parameter.

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 tool with an output schema present, the description covers coordinate semantics, face selection, both geometry payload formats, and the verification behavior. The main residual gap is that nothing explains what the tool returns or how a failed verification surfaces.

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 25%, so the description must compensate, and it largely does for circles and rectangles by giving explicit JSON shapes and a worked example for each. However, it never restates that circles/rectangles are JSON-encoded strings (a non-obvious encoding visible only in the schema's type), and instance is documented only in the schema, so coverage is not fully closed.

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 ('cut holes through the sheet ... on a face') and pins down the defining characteristic that separates it from sibling cut tools: placement in WORLD coordinates rather than sketch coordinates. An agent can distinguish it from hole, sheet_metal_cut, or extrude-based cuts from the description alone.

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 tells the agent how to obtain a face_index ('use find_face / list_faces') and implicitly warns off work-plane cuts, which is useful routing. But it never names the alternative cut tools (hole, sheet_metal_cut) or states when this tool should be chosen over them, leaving the sibling selection ambiguous.

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 of behavioral disclosure and does not meet it. It never says whether the deletion is permanent, undoable, or transactional, what happens with an invalid or out-of-range index, or whether the model must be in a specific state. Only the index provenance hint adds context.

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

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

A single front-loaded sentence with no filler and the key scoping information first. Its brevity is efficient rather than bloated, though it leaves the definition under-specified for a destructive 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?

An output schema exists so return values need no explanation, but for a 2-parameter destructive operation with zero annotations the description should cover irreversibility, permission/connection requirements, and error behavior. None of that is present, leaving the agent to guess at the consequences of calling it.

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%: the 'instance' parameter is documented in the schema but 'index' has no description there. The description partially compensates by tying index to list_constraints and scoping it to assembly constraints, though it does not say whether the index is 0- or 1-based or relative to the listing order.

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 ("Delete an assembly constraint") plus the addressing scheme ("by index"), which separates it from delete_feature and delete_occurrence by resource type. It stops short of explicitly naming the sibling it is not, but the resource noun 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?

The parenthetical "(see list_constraints)" gives implied guidance on how to obtain a valid index, which is a real routing hint. There is no statement of when to prefer this over suppress_feature or delete_occurrence, and no prerequisites or exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that multiple indices are deleted in reverse order automatically, but it does not state whether deletion is irreversible, whether it requires confirmation, or what happens on invalid indices.

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

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

The description is short and front-loaded: the core action appears first, followed by the discovery hint and then the parameter format. Every sentence adds useful invocation information.

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

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

The description gives enough to call the tool correctly, including the required index format and reverse-order deletion behavior. Because an output schema exists, return-value details are not required, though the lack of safety/irreversibility context is a minor gap for a destructive operation.

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

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

The schema only gives a bare string type for the required indices parameter, so the description meaningfully compensates by explaining the comma-separated format and giving an example. The instance parameter is documented in the schema itself, so the description does not need to repeat 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?

The description states a specific verb and resource: deleting one or more features by index. It also distinguishes the target from related operations by specifying feature indices and pointing to list_features() for discovery.

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 usage context by telling the agent to use list_features() to find valid indices. It does not, however, explain when to delete versus suppress a feature or mention prerequisites/exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden for a destructive mutation. It never states whether removal is permanent, whether dependent constraints/features are affected, or whether it must run inside a transaction, all of which matter for a delete 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?

One tight sentence with the action front-loaded and the prerequisite tucked into a parenthetical. Nothing is wasted, though it is terse enough to leave behavioral gaps unaddressed.

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, but for an unannotated destructive tool the description gives no consequences, reversibility, or error conditions. The only real completeness win is the index lookup hint.

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?

Coverage is 50%: the 'instance' parameter is self-documented in the schema, while the required 'index' has no schema description at all. The description partially compensates by pointing to list_occurrences as the source of the index, but adds no format or origin detail beyond that hint.

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 ('Remove') and resource ('a component from the assembly'), which distinguishes it from siblings like delete_feature or delete_constraint. Minor friction: the name says 'occurrence' while the description says 'component', though the parenthetical tie to list_occurrences bridges that.

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 parenthetical 'see list_occurrences for the index' gives a concrete prerequisite for obtaining the required argument, which is genuine usage guidance. However, it says nothing about when not to use it (e.g. versus delete_feature/delete_constraint) or what prerequisites like an active document are needed.

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?

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 load and does so unusually well: it enumerates pre-bound objects, discloses that COM units are centimeters while the wrapper is mm, warns against CastTo/gencache.EnsureDispatch, notes SilentOperation suppresses dialogs, explains timeout/cancel semantics and the CANCEL_GRACE interrupt, and names the return (stdout+stderr or a named-COM-error traceback). This is the kind of behavior an agent could not infer from schema or annotations.

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

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

Front-loads purpose in one line, then moves to pre-bound names, persistence, units, late binding, and failure modes. It is long and reads as a dense run-on block rather than cleanly sectioned prose, but nearly every line carries operational signal rather than 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?

Complete for a high-complexity arbitrary-code tool: persistence model, unit trap, cancellation path, error surface, and multi-instance namespace isolation are all covered, and an output schema exists so return formatting need not be re-explained.

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` documented), so the description must compensate and does: `code` is Python source with documented pre-bound names, `undo_on_error` explains it wraps the run in one undo transaction and rolls back on raise, and `timeout` explains cancelled() flips True then an interrupt occurs (0 = none). Only `instance` is left to the schema, where it is already described.

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 against the live Inventor connection — and implicitly frames itself as the raw escape hatch that the many single-purpose siblings (draw_line, extrude, fillet) do not cover. An agent can immediately tell this is the general scripting entry point rather than a modeled operation.

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

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

Gives concrete operating guidance: follow long calls with call_status(wait_seconds=30), use cancel_call to stop, put reusable helpers in a file/startup.py, and note that variables persist until restart or reload_api. It lacks an explicit 'prefer the dedicated tool over scripting when one exists' exclusion against the ~70 modeling siblings, which is the main missing routing cue.

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 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 behavioral burden, and it discloses almost nothing: no statement of what happens if an edge index is invalid or the radius exceeds the body geometry, no note on whether the operation is transactional/undoable, and no indication of which solid is modified. Only the units (mm) are surfaced.

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 and units are front-loaded in the first sentence, and the argument list is short and purposeful. The arg lines partially restate the schema, but they add the mm unit and the index-format example, so little is wasted.

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

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

An output schema exists, so return values need not be explained. But for a geometry-mutating tool with zero annotations, the definition says nothing about failure modes, target-body selection, or whether the change is reversible — information an agent needs before invoking a destructive CAD operation.

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: it documents radius units (mm) and specifies the edge_indices format as a comma-separated list with the example "1,2,3", plus a pointer to status() for valid values. The remaining instance parameter is already documented in the schema, so the gaps are effectively closed.

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 gives a clear verb and resource ('Add fillet (rounded edge) to edges of the solid body') and even glosses the term 'fillet', so an agent unfamiliar with CAD terminology understands it. It does not distinguish itself from the sibling chamfer tool, which is the nearest alternative operation, 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?

There is one concrete usage hint: 'Use status() to see edge count' for discovering valid edge_indices. However, it never says when to choose fillet over chamfer, which body it applies to when multiple exist, or any precondition/limitation, leaving the agent to infer the selection context.

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

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

No annotations exist, so the description carries the full burden; it does disclose that the result is a string edge index and that tolerance defaults to 0.1 mm, which is helpful. It never says what happens if no edge matches (error, None, nearest match) or if multiple edges match within tolerance — the critical failure modes for a finder 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 purpose and return value, then the arg breakdown; every line carries real information. The 'Args:' docstring style is slightly verbose but not wasteful.

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 8-parameter geometry-query tool with no annotations and an output schema, so return-value explanation is rightly omitted. Still, the ambiguous cases an agent will hit — no match, multiple matches, unit/instance scoping interactions — are unaddressed, leaving gaps that matter for correct invocation.

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

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

Schema description coverage is only 13% (just 'instance'), so the description must compensate, and it does: it explains the x/y/z target coordinates, the use_x/use_y/use_z matching toggle semantics ('False = ignored'), and the tolerance unit and default. Only 'instance' is left to the schema, and the schema does document that one.

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 an edge by its midpoint coordinates') and discloses the return type (edge index string). The added note about flange use implicitly separates it from list_edges, though it never names that sibling 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?

'Useful for flange — locate the edge to bend without printing all edges' gives a concrete use scenario and hints at the list_edges alternative, but there is no explicit when-not-to-use guidance or named alternative tool.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return type, default min_area filtering for tiny edge faces, and default centroid tolerance, but it omits important behavior such as what happens when no face or multiple faces match.

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

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

The description is short, front-loaded with purpose and return value, and uses a clean Args block for parameter meanings. Every sentence adds useful information with no repetition or filler.

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

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

An output schema exists, so return-value details need not be expanded. For a 9-parameter search tool with no annotations, the description covers the core matching behavior well, though it could mention coordinate frame assumptions or no-match/multi-match 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 description coverage is only 11%, so the description must explain parameters, and it does: x/y/z are target centroid coordinates, use_x/y/z control which coordinates are matched, and min_area/tolerance have defaults and purpose. The instance parameter is documented in the schema rather than the description, which is a minor gap.

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

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

The description states a specific verb and resource: "Find a planar face by its centroid coordinates (mm)," and it explicitly says it returns a face index string. It is clear about what the tool does, but it does not explicitly contrast itself with siblings such as list_faces or find_edge.

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 a concrete usage context: sheet metal Cut, locating the outer panel face to sketch on. That is clear guidance for when the tool is useful, though it does not state when not to use it or name alternative tools for other face-finding cases.

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 disclose meaningful behavior: the result unfolds in Flat Pattern, bend radius/depth tie to sheet thickness, and mitering only happens when a loop is passed in one call. It also explains bending direction relative to face ownership. It omits permission/auth needs and whether the feature is reversible (deletable via delete_feature), which keeps it below 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?

Front-loads the core action, then the differentiator, then the critical multi-edge rule and bend-direction gotcha, then the arg list. Every line carries distinct information; nothing is redundant with the schema beyond intentional clarification.

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 mutation tool with an output schema, the description plus schema cover the call mechanics almost completely, including the non-obvious mitering constraint. Minor gaps remain on failure modes (e.g. what happens if an edge is not on a sheet-metal face) and the multi-instance parameter, which the description doesn't mention.

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 nearly closes the gap: it documents edge_indices format (comma-separated, use find_edge), distance units and default (mm, 25), angle units and default (degrees, 90), auto_miter, miter_gap's 'GapSize' meaning (from sheet metal rule), and enumerates height_datum values with the default. The one remaining parameter, instance, 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 (bent wall) to one or more edges') and explicitly distinguishes itself from a sibling ('Real sheet-metal feature (vs Extrude)'). An agent can tell what it produces and how it differs from extrude without opening either 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 a concrete usage rule: put all edges of a loop in ONE call so corners auto-miter, since separate calls leave open corners. It also routes to find_edge for locating edges and gives direction guidance (use the wall's inner-face edge for an inward flange). It does not compare against related siblings such as sheet_metal_face or corner_round, so it stops short of full when/when-not coverage.

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 discloses the implicit mutation ('Creates the flat pattern if the part has none'), the exact layer taxonomy of the output file (OUTER/INNER/IV_BEND*), and what is deliberately excluded (tangent lines, sketches). Gaps remain: behavior when the active document is not a sheet metal part, and whether an existing DXF at `path` is overwritten.

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 scope, then the args block; no filler sentences. It is somewhat dense and parenthetical, but every clause (layer legend, exclusion list, empty-path behavior) conveys operational information rather than restating the name.

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 description covers the mutation side effect, output file layout, and option semantics. It falls short only on failure modes (non-sheet-metal active document, file overwrite, format/path mismatch), which matter for a tool that writes a file to disk.

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 largely does: it explains `path` semantics including the empty-string sentinel, restricts `format` to DXF or DWG, and defines `bend_lines` as emitting bend lines on their own layers. Only `instance` is left undocumented in the description, and the schema covers that one, so nothing is fully dark.

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 — generating/reporting the flat pattern of the active sheet metal part — and enumerates what it yields (flat size, thickness, bend count, DXF/DWG export). An agent can distinguish it from modeling siblings like sheet_metal_face or flange, though it never names a specific sibling to contrast with.

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 'Empty: just report the flat size' clause effectively gives the two operating modes (report-only vs. export), which is genuine when-to-use guidance. It also notes the tool will create the flat pattern if none exists, so the agent knows it need not run a separate step. No explicit when-not or prerequisite conditions (e.g. active document must be sheet metal) are stated.

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

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

With no annotations at all, the description carries the full burden and does substantial work: it discloses that each member becomes a Content Center custom-length part file (one file per profile/length, reused), where those files land, and that it returns placements plus a saw cut list. It still omits failure behavior (e.g. what happens with no active assembly or missing skeleton) and whether members are adaptively constrained to the skeleton.

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

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

It is front-loaded with the one-line purpose before the argument block, and the parentheticals (Frame Generator has no API; roll 90 turns a U sideways) each resolve a real ambiguity rather than padding. Length is proportionate to a six-parameter tool with a nested member list.

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 brief return summary is sufficient, and the argument documentation is thorough for a complex nested-array call. The remaining gap is environmental: it never states the precondition that an assembly document must be active or what the tool does when the skeleton lines are 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 coverage is only 17%, so the description must compensate, and it does: the members array is shown with a concrete JSON example and every per-member key is defined beyond the schema — roll in degrees with a worked U-section case, anchor 'center' vs 'origin', and extend as [start,end] mm with negatives to stop at a crossing member. The only undocumented parameter, instance, is already described 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 definition opens with a specific verb and resource — building a steel frame of structural profiles along skeleton lines in the active assembly — and anchors it to a known concept (Frame Generator) that has no API. An agent can tell this apart from generic profile tools like extrude or place_component 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?

It establishes the operating context (active assembly, skeleton lines) and ends with an explicit verification step — 'Check with view_image' — which tells the agent what to do after calling. It does not name alternatives or state when not to use it (e.g. when to fall back to place_component plus constrain), so the routing guidance is implicit rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. 'Get' plus 'Returns JSON list' establishes it as a read with a list result, but it does not say whether model, user, and reference parameters are all included, what an empty document returns, or the ordering.

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

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

Two short sentences with the resource and the return shape front-loaded; nothing is wasted and nothing needs to be re-read.

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 and the one optional parameter is fully documented, so the description need not explain return values or instance semantics. Only a note on which parameter types are returned would make it fully complete.

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

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

Schema description coverage is 100% and the single optional 'instance' parameter is fully documented in the schema. The description adds nothing about multi-instance selection, so 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?

States a specific verb and resource ('Get all parameters of the active document') and the return shape. It is distinguishable from the mutation siblings add_parameter and set_parameter, though it never names 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?

The phrase 'active document' implies scope, which indirectly points at activate_document, but there is no explicit when/when-not guidance and no mention of set_parameter or add_parameter as the write alternatives.

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

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

No annotations are provided, so the description carries the full burden. It does disclose that this is a bidirectional state mutation (grounded=True vs False) rather than a one-way write, which is genuinely useful, but says nothing about preconditions (active assembly, component being an occurrence), failure modes, or whether the change is reversible.

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

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

Two short lines, front-loaded with the action and backed by per-argument notes; nothing is padded. The docstring 'Args:' formatting is slightly mechanical but costs nothing in length.

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

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

An output schema exists, so return values need not be explained. However, for a state-changing assembly operation with zero annotation coverage, the description omits the invocation context an agent needs (must an assembly be active? must the document be open?) and any error behavior, leaving a real 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%, and the description compensates well: it explains that 'index' is a component index obtained from list_occurrences and defines the boolean semantics of 'grounded' ('True to ground, False to release'), neither of which appears in the schema. The third parameter ('instance') is covered by 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 pair and resource: 'Ground (fix in space) or unground a component', and the parenthetical clarifies what grounding means. An agent can distinguish this from constraint-oriented siblings like constrain or constrain_faces, though the description never explicitly names those alternatives.

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 one useful prerequisite: the index comes from list_occurrences, which is named explicitly. It does not say when to ground versus release versus use a constraint (constrain/constrain_insert) instead, so the agent must infer the assembly-fixing use case.

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

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

With no annotations, the description carries the burden well: it discloses mm units, native HoleFeature behavior, through-all depth semantics, ISO Metric 6H tapping, and auto coarse pitch. It omits side effects, required document context, and transaction/permission considerations.

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 core purpose, then uses a compact Args section to explain each parameter. The structure is efficient and every sentence adds practical 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?

Complete enough for a mutation tool with an output schema: it explains the feature type, defaults, units, threading behavior, and parameter meanings. It could be stronger by stating prerequisites such as an active part or sketch context.

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

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

Schema description coverage is low at 14%, but the description compensates by documenting x, y, diameter, depth, tapped, and pitch with useful format and default semantics. The instance parameter is also documented in the schema itself, so coverage is effectively strong.

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 native Inventor HoleFeature. It distinguishes the operation from extrude cut and notes compatibility with circular_pattern, but does not explicitly differentiate from the sibling hole_linear, leaving some ambiguity among related hole tools.

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

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

Gives clear usage context by saying this creates a proper Hole feature rather than an extrude cut, and explains plain vs tapped hole support. It does not explicitly state when to prefer this over hole_linear or what prerequisites apply.

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

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

Without annotations, the description does useful work: it discloses that the hole persists through resizing, that drill direction is auto-resolved by a volume check, and that `tapped` produces ISO metric 6H threads. What is missing is failure behavior, preconditions (does the face have to exist and be planar on the active part?), and confirmation that this is a mutating modelling 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 a two-line behavioural summary, then a scannable per-argument list where each line adds distinct meaning. No filler sentences, though the inline examples make it longer than strictly minimal.

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 15-parameter mutation tool, the description plus an existing output schema leaves an agent able to construct a call: geometry anchors, thread/counterbore options, and persistence semantics are all covered. The only gaps are the `instance` selector, which the schema documents, and precondition/error behaviour.

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 7%, so the description carries the load and largely does: it explains every geometric argument with units and an example ('z', 25 = top face at Z=25mm), defines depth 0 as through-all, and clarifies diameter as thread nominal when tapped. Only `instance` and the numeric defaults (e.g. diameter 5.5, cbore 0) are 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?

The description opens with a specific verb and resource: a hole placed parametrically from two edges of a face, plus the key distinguishing trait that it survives part resizing. It never explicitly contrasts with the sibling `hole` tool, so an agent must infer the difference from the placement method.

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 rather than stated: the linear/persistent-placement framing suggests when this beats a plain `hole`, and the drill-direction note removes a decision. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent has to infer the choice from the sibling 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?

No annotations are provided, so the description carries the full burden, and it does disclose a non-obvious side effect: the STEP is copied into dest_folder because Inventor writes parts next to the .step file. It also enumerates what is returned (path, type, overall bbox, per-component bbox/volume). It omits overwrite behavior, permission requirements, and failure modes for a write operation.

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

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

The purpose leads, the rationale for the copy follows, and parameters are grouped cleanly under Args. Every sentence carries information the agent needs; nothing redundant.

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 four-parameter import tool with no annotations, the description covers purpose, the key side effect, and the workflow hand-off to place_component. The output schema already covers return values, so the remaining gap is minor (overwrite/permission semantics rather than structural information).

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

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

Schema coverage is only 25%, so the description must compensate, and it explains all three parameters it lists: step_path is the downloaded .step/.stp, dest_folder is where Inventor files go, and name defaults to the STEP file name. The fourth parameter (instance) is documented in the schema itself, leaving no meaningful 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 ('Import a vendor STEP file ... as Inventor files in dest_folder') plus scope details like hinge/lock/gland examples. Clearly distinct from siblings such as create_part, place_component, and execute_python.

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 downstream guidance ('use them to find mounting faces and axes before placing it with place_component'), which tells the agent when this tool fits in the workflow. It doesn't state exclusions or name alternatives for other file formats or import paths, so it falls 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 full behavioral burden. 'Snapshot' and 'diagnostic queries' imply a read-only inspection scoped to the active part, but the definition does not explicitly confirm no mutation, permissions/auth needs, behavior with no active part, or other side effects.

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

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

Two sentences with no wasted text: the first front-loads the scope and returned diagnostic fields, and the second justifies the value over multiple calls. It is appropriately sized for the tool.

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