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

Annotations set readOnlyHint=false and destructiveHint=false, so the agent knows this mutates state non-destructively. However, the description adds nothing beyond that: it doesn't say whether the switch triggers a rebuild, how it interacts with the optional doc parameter, or what happens if the name is unknown.

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

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

A single short sentence with no filler, but it is terse to the point of under-specification rather than efficient. There is nothing front-loaded beyond the bare action.

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

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

This is a state-mutating tool with two parameters, one of which is required but undocumented in both schema and description, and no output schema. Given that, the description should cover the required parameter and the effects of the switch; it covers neither.

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 50%: only `doc` is documented, while the required `name` parameter has no schema description at all. The tool description does nothing to compensate — it never clarifies that `name` is the target configuration, nor the scope of the switch when `doc` is omitted.

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

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

The description gives a specific verb ('switch to') and resource ('another configuration'), so the agent knows this changes the active configuration. It does not distinguish itself explicitly from siblings like sw_list_configurations, sw_add_configuration or sw_delete_configuration, though the verb 'switch to' implicitly signals an existing configuration.

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., the configuration must already exist, must be listed via sw_list_configurations first), and no statement about what happens to the previously active configuration. The agent must infer everything.

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

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

Annotations already declare that this is a non-read-only, non-destructive operation. The description adds conceptual context about configurations being variants, but does not disclose operational behavior such as duplicate-name handling, default activation, or effects on existing configurations.

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

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

The description is a single front-loaded sentence with concrete examples and no wasted text. It is perhaps terse for a six-parameter mutation tool, but structurally clean.

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 six parameters, only 50% schema description coverage, and no output schema, the description is too thin to fully explain configuration creation. It omits activation behavior, suppression semantics, and duplicate-name implications that an agent would need.

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 examples ('M4' with hole diameter 4.5, '7 inch' with a longer arm) add useful insight into how 'name' and 'values' relate to dimension overrides. However, it does not explain 'activate', 'suppress', or 'description', and schema coverage for those parameters is incomplete.

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: 'Add a configuration (variant)'. This clearly distinguishes it from siblings like sw_activate_configuration and sw_delete_configuration by verb, although it does not explicitly name 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?

There is no explicit when-to-use guidance, no exclusions, and no comparison to alternative configuration tools. Usage is only implied by 'Add a configuration', with examples illustrating variants rather than selection criteria.

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

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

The annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered; the description only adds that the operation is additive ('one more'). With that lower bar, the description still omits what happens on failure (no active drawing, unresolved model_path), whether the view is placed immediately on the sheet, and whether the call can be undone.

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 zero filler, and the additive nature is stated up front. It is arguably too terse for a 5-parameter mutation tool, but there is no wasted text.

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

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

For a five-parameter mutation tool with no output schema and only midpoint schema coverage, the description does not say what is returned (a view object, a name, a status), what the call requires of document state, or how position and scale are interpreted. Key facts an agent needs to call it correctly 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 60%: doc, view, and position are documented in the schema, but scale (unit convention? ratio vs. factor?) and model_path (which model file, relative to what?) have no description anywhere. The description contributes nothing about any parameter, so the two undocumented ones remain opaque.

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

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

The description gives a specific verb-plus-resource ('add... model view') and scopes it to the active drawing, so an agent knows this creates a drawing view rather than a model feature. It does not distinguish itself from the sibling sw_create_drawing, which is the most likely confusion point for an agent deciding how to start a drawing.

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 sw_create_drawing, nor on prerequisites such as an already-open drawing or an already-loaded model. The phrase 'active drawing' hints at a precondition but never states that you must create a drawing 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?

Annotations only tell us it is not read-only and not destructive, which is nearly the whole safety story for a mutation. The description does not disclose that it adds a new equation to the model, whether it errors on existing/duplicate equations, that equations evaluate on rebuild, or any auth/connection requirement. For a model-mutating tool this leaves real behavioral gaps.

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 compact sentence with no filler and the core mechanism front-loaded. Brevity is close to under-specification, but nothing is wasted.

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

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

With no output schema and only minimal annotations, the description should say what a successful call produces (new equation added) and how it interacts with existing equations. Given the tool mutates the model and has strong sibling overlap, this is too thin to be called 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 schema already gives examples for dimension ('D1@Boss-Extrude1') and expression ('"span" / 2'), including the quoting rule. The description adds only the higher-level notion that the expression may reference globals/other dimensions, 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?

Specific verb+resource: 'Drive a dimension with an expression' clearly conveys the operation and its mechanism (global variables / other dimensions). It is distinguishable from sw_set_variables and sw_set_dimension, though it never explicitly contrasts itself with those siblings or acknowledges it creates a new equation (pairs with sw_list_equations / sw_delete_equation).

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 (document must be open, model must support equations), and no mention of alternatives such as sw_set_variables for creating variables or sw_set_dimension for a static value. The agent has to infer all routing decisions.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-but-not-destructive profile is covered. The description adds nothing beyond that: it does not say the mate constrains assembly degrees of freedom, that it mutates the active document, whether mates are reversible/removable, or what errors occur for invalid entity pairs.

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 front-loaded sentence with no filler; the verb leads and the enumeration is tight. The parenthetical lists are dense but each item earns its place by naming covered mate types.

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

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

For a 12-parameter tool with 15 mate types where valid parameters vary by type, no output schema and only 58% schema coverage, a single sentence is not enough. Missing are per-type parameter requirements, entity selection rules, and what a successful mate returns or how failures surface.

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?

At 58% schema coverage across 12 parameters, the description contributes a little by grouping mate types into families, implying symmetric/width need extra_entities and limit distance/angle use min/max values. But it never maps flip, alignment, doc, or which parameters are required per mate type, leaving several parameters undocumented in both schema and prose.

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 (mate) and resource (components) and enumerates the mate families the tool covers, which maps directly onto the 15-value mate_type enum. An agent can tell this is the assembly-mating tool; no sibling (insert, interference, explode) competes for the same action, though the description never says so 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?

Usage is only implied: the family grouping (standard / advanced / mechanical) hints at which mate type to choose, but there is no statement of when to prefer this over sw_insert_component or sw_interference, and no prerequisite such as needing an active assembly with existing components to mate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only what the tool yields (mass and CG); it says nothing about units, whether it requires an assembly versus a part document, or how it behaves if the document is empty or unloaded.

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

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

One sentence, front-loaded with the resource and outputs, with no filler. The parenthetical is illustrative rather than redundant, though it is informal for a tool description.

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

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

For a simple read-only query with a fully documented optional parameter this is close to adequate, but with no output schema the description should say more about the return shape and units (mass and CG coordinates) so the agent knows what it will receive.

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

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

The single optional 'doc' parameter is fully documented in the schema (100% coverage), so the baseline is 3. The description adds no meaning about accepted formats (title vs path) or the fallback-to-active-document behavior beyond what the schema already states.

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 resource (total mass and centre of mass of the assembly) with a concrete verb implied ('compute/report'), and the parenthetical anchors the purpose to a real engineering task. It does not, however, differentiate itself from the sibling sw_mass_properties, which an agent could easily 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?

Usage is only implied: the '(balance a drone on its CG)' note hints at a scenario, but there is no explicit when-to-use, no prerequisite (e.g. an assembly must be open), and no routing to or away from sw_mass_properties.

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

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

The annotations already flag this as non-read-only and destructive, and the description adds useful context that source files are opened read-only and never saved. It identifies the output location but does not discuss overwrite behavior or recursive traversal, which the schema partially covers.

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

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

The description is a single front-loaded sentence with zero wasted text. It states the action, scope, safety context, and destination efficiently.

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

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

For a six-parameter batch export with no output schema, the description covers the core action and source-file safety but omits return/error behavior and the effects of recursive, material, and file_format. It is adequate but not 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?

With schema description coverage at 67%, the schema already documents folder, pattern, material, and overwrite. The description reinforces folder/matching-file semantics and the output path, but adds little for material, overwrite, recursive, or file_format.

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 every matching file in a folder. It also names the destination pattern, and the folder-wide batch scope distinguishes it from single-file export siblings.

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

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

The batch nature is implied by 'every matching file in a folder', but there is no explicit guidance on when to use this instead of sw_export or when not to use it. No prerequisites or exclusions 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?

While the annotations flag this tool as destructive and non-read-only, the description fails to add specific behavioral context, such as whether the operation modifies the underlying document directly, saves the BOM to a local filesystem, or creates a new linked object. It only mentions the optional CSV output.

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 highly concise and immediately tells the agent what output data to expect from the function call, putting the most important information (the list contents) first.

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 definition is incomplete regarding its nature. The tool's operational intent is vague; does it 'list' (read) or 'generate/save' (write)? While parameters suggest export, the description does not explicitly define the tool's core action relative to the document state.

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?

Given that parameter coverage is 100%, the description doesn't need to define fields. However, it provides excellent semantic context for the result, specifying the complex data structure of the BOM (item, configuration, material, etc.), which is more valuable than the simple 'document title or path' schema description.

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

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

The description clearly identifies the tool's function as generating a 'parts list' (Bill of Materials) and lists the key data points included (item, part, configuration, quantity, etc.). The specific content focus helps distinguish it from broader component listing tools in the same CAD suite.

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 definition provides almost no usage guidance. It does not specify whether this tool should be used when a designer needs a procurement list versus when they need a technical schematic list, nor does it provide any prerequisites (e.g., the assembly must be defined) for calling it.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this adds rather than removes something, and the description does not contradict that. But beyond the design tip, it discloses nothing behavioral: not that a feature is added to the feature tree, not whether it can be reverted (sw_delete_feature/sw_undo), and not what happens when edges resolve to 'all'.

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 the core action first and the useful aside second; nothing is wasted and no padding.

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

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

For a 5-parameter geometry mutation with no output schema, the definition covers the what and one design rationale but omits prerequisites (active document / part context), the effect on the feature tree, and the return value (e.g. the new feature name useful for later sw_delete_feature or sw_list_features calls).

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 60%, so roughly half the parameters carry their own documentation (doc, name, edges). The phrase 'angle-distance chamfer' does add meaning by revealing that angle and distance jointly define the cut, but it gives no default or range context and says nothing about the angle parameter's 0-90 constraint or how edge points are interpreted.

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 ('Bevel edges') plus the defining mode ('angle-distance chamfer'), which tells the agent exactly which operation variant this performs. It implicitly differentiates from sw_fillet by naming fillets as the alternative, though it never explicitly contrasts the two tools' parameterization.

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 'prints better than fillets on downward edges' gives a real decision cue for choosing chamfer over the sibling sw_fillet in one specific geometry case. However, it offers no guidance on the far more common cases (when not to use a chamfer, prerequisites such as an open part document, or what happens with the default edges='all').

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful return behavior (pass/fail per check and measured values), but does not explain what requirement checks are evaluated, error behavior, or any side effects beyond reading.

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 what the tool does and what it returns, with no wasted text. Brevity is appropriate here, even though the description is incomplete elsewhere.

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

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

For a tool with eight optional parameters, 25% schema description coverage, and no output schema, the description is too thin. It leaves the agent without enough detail about what each requirement check means, how max/min parameters are interpreted, or what the returned pass/fail structure contains.

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%: only doc and fits_build_volume have descriptions, while max_size, min_size, max_mass_kg, min_mass_kg, max_volume_mm3, and min_volume_mm3 are undocumented. The description does not compensate by clarifying those parameters, their units, ordering, or how they relate to the checks.

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 the model against requirements, and specifies the return shape as pass/fail per check plus measured values. However, 'requirements' remains broad and no sibling tool is named to sharpen the distinction from related checks like sw_measure or sw_print_check.

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

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

Provides no explicit when-to-use guidance, prerequisites, or alternatives. An agent can infer that it is for requirement checks, but gets no routing help versus sw_measure, sw_mass_properties, or sw_print_check.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is covered. The description adds nothing beyond restating the operation: it doesn't say a new feature node is added to the tree, that it is parametric/editable, or how the axis reference must be supplied.

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 tight sentence with the core operation front-loaded and examples supplying cheap extra signal. No waste.

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

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

For a 6-parameter mutation tool with no output schema and only partial schema coverage, the one-line description is far too thin — it leaves the features list, total_angle semantics, and axis-reference requirements entirely to the agent's inference.

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% and the description mentions no parameters at all. Key parameters like features (which features get patterned) and total_angle (partial vs full revolution, which the 'bolt circles' example only hints at) are undocumented in the description and absent from 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?

Specific verb ("Repeat") plus the concept of a circular pattern around an axis, with concrete example use cases (bolt circles, blades, arms, spokes). An agent can distinguish it from sw_linear_pattern and sw_sketch_pattern by implication, though no sibling is explicitly named.

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 examples imply usage contexts (rotational symmetry), but there is no explicit statement of when to choose this over sw_linear_pattern, sw_sketch_pattern, or sw_curve_pattern, nor any prerequisites mentioned.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description usefully adds that the scope is document-level only (not face/feature appearance) and that the revert target is the material colour, but it omits whether the removal is undoable, whether it requires an open/modified document, and what is returned.

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

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

One sentence, front-loaded with the action and resource, with the resulting state appended. Every clause earns its place and 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 one-optional-parameter, non-destructive toggle with annotations present and no output schema, this is close to sufficient. The remaining gaps are edge cases: behavior when no document-level appearance exists, and whether the change is undoable.

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

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

The single optional 'doc' parameter is fully documented in the schema at 100% coverage, including the default-to-active-document behavior. The description adds no additional meaning about path formats or title resolution, so the baseline 3 applies.

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

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

Specific verb ('Remove') plus a precise resource ('document-level appearance') and the observable effect ('material colour shows again'). It clearly contrasts with set-style operations, though it never names sw_set_appearance as the counterpart, so sibling differentiation is implied rather than stated.

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 stated outcome ('so the material colour shows again') implies the situation in which an agent should reach for it, but there is no explicit when-to-use versus sw_set_appearance, no precondition that an appearance must exist, and no statement of what happens if none is set.

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

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

The description adds significant behavioral context beyond the 'destructiveHint: true' annotation by detailing the specific cause of potential failure (unsaved changes) and the mechanism to override that failure (discard_changes=true).

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 highly efficient, using two clear sentences to convey the function, the failure mode, and the required override 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?

The description is contextually complete for this operation; it covers the primary action, the failure condition, and the required remediation/override, leaving no ambiguity in decision-making.

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

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

Although schema coverage is only 50%, the description provides crucial semantic meaning for the 'discard_changes' parameter, explaining its functional role in bypassing the document state safety check. This makes up for the incomplete 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 clearly states the tool's function: to close a document. While simple, it provides enough context to distinguish it from tools like sw_save or sw_new_document by defining the action's immediate consequence regarding state.

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

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

It explicitly defines the primary behavioral constraint: refusal due to unsaved changes. This tells the agent precisely when the default call will fail and when it must include the discard_changes parameter.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond the name: it does not say whether the collapse is reversible via sw_explode, whether it targets the active document only, or what state change results.

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

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

A single short sentence with no wasted words and the action front-loaded. Its brevity is appropriate in form, though it borders on under-specification rather than being genuinely economical.

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

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

The tool is simple (one optional parameter, no output schema, non-destructive annotation), so little is strictly required. Still, an agent calling it cannot know from the description whether an exploded view must currently exist, which document is affected, or how to restore the exploded state.

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

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

Schema coverage is 100% and the single 'doc' parameter is fully documented as a title or path defaulting to the active document. The description adds no further parameter meaning, so the baseline 3 applies.

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

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

States a specific verb ('Collapse') and resource ('the exploded view'), so the agent can tell it reverses an explode operation. It does not explicitly name its inverse sibling sw_explode, so the differentiation is left implicit.

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

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

There is no guidance on when to use this versus sw_explode, no precondition (e.g. an exploded view must exist), and no statement about what happens when nothing is exploded. The agent must infer usage entirely from the verb.

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

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

The description defines the domain of the tool (Boolean operations) but adds little to the behavioral context beyond what is already implied by the action and the enum values in the schema. It does not contradict the non-destructive/non-readonly hints.

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

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

The description is a highly concise single sentence. Every word serves to define the tool's capability and scope.

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?

It provides a very strong overview of the tool's high-level function. Given the schema is detailed, the description acts as a solid, brief conceptual summary for the AI.

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

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

With schema description coverage at 80%, the description primarily adds high-level context. It does not offer unique insights into why specific inputs like 'main_body_point' are required versus what they represent geometrically, making it adequate but not impactful.

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?

Clearly identifies the function as a Boolean operation between bodies within a multibody part. It specifies the three types of operations supported (union, subtract, intersect), which is effective.

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 only explains what the tool is, not when to use it. There is no comparison to alternative tools (e.g., sw_cut_extrude) or any exclusionary criteria, leaving the agent to rely entirely on its own reasoning about the tool's functionality.

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

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

Annotations only declare non-read-only and non-destructive; the description adds the meaningful side effect that the app may be launched if not running, plus a consent requirement. It doesn't say what happens on failure (no SolidWorks installed, existing session) or whether the call is idempotent, so it stops short of full disclosure.

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

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

A single sentence that front-loads the action and appends the gating condition. Nothing is redundant or padded.

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

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

For a one-optional-param tool with no output schema, the description covers what it does, its side effect, and its consent gate. Only the post-call state (connected vs already connected, failure modes) is left unaddressed, which is minor here.

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

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

With one optional parameter and 100% schema description coverage, the schema already explains user_approved in detail. The description's permission phrasing reinforces but does not extend that meaning, so the baseline 3 applies.

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

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

States a specific verb and resource (connect to SolidWorks) plus the scope of starting the application if needed. It is distinguishable from document-level siblings like sw_open or sw_new_document because it targets the application connection, though it never names those siblings 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?

The permission prerequisite is stated ('only with the user's permission'), and the parameter description clarifies the escape hatch for clients that cannot prompt. However, it never says when to call this versus sw_status or sw_health, nor whether it must precede all other sw_* calls or is safe to call repeatedly.

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

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

Annotations only say it is a non-destructive write; the description adds real semantic content by explaining that the thread is cosmetic/lightweight and is represented as drawing annotation rather than modeled geometry. It still doesn't say what happens to an existing thread on the same edge or what the tool returns, but the key behavioral distinction is disclosed.

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

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

One sentence with zero filler, front-loading the resource and the defining cosmetic/lightweight trait before the placement constraint.

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 feature-creating mutation with five parameters and no output schema, the description leaves meaningful gaps: the optional 'length' has no explanation anywhere, the supported size format breadth is unclear, and there is no note about the required pre-existing circular edge or error behavior.

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

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

Schema coverage is 80% and the schema already documents size ('M6', 'M10x1.25') and edge_point ('Point on the circular edge'). The phrase 'on a shaft or hole edge' reinforces edge_point but adds no new format or constraint information, and the undocumented 'length' parameter is not clarified 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?

States a specific verb+resource ('Cosmetic thread') and its location constraint ('on a shaft or hole edge'), plus the qualifying trait 'lightweight, shows in drawings'. It does not explicitly distinguish itself from the sibling tools sw_thread and sw_hole_wizard, which an agent could easily confuse with this one.

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: cosmetic threads go on circular edges of shafts or holes. There is no explicit 'use this instead of sw_thread when...' guidance, and no prerequisites (existing edge, active document) 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is an additive write. The description adds the model-mm unit convention and the bend_radius purpose for tube-ready polylines, but says nothing about whether an active document is required, what happens on invalid geometry, or whether it errors when a sketch already exists.

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

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

A single dense sentence covering geometry types, units, and downstream uses with no filler. It is slightly run-on, but the purpose and the entity list are front-loaded, so an agent can act on it quickly.

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

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

For a 3-parameter creation tool with no output schema, the description supplies the geometry vocabulary, unit convention, and integration targets, which is enough to call it correctly. The remaining ambiguity about document targeting is resolved by the doc parameter's own schema description.

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

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

Schema description coverage is 67%, so the schema carries most parameter meaning (per-field '[x, y, z] in model mm', bend_radius min-exclusive constraint). The description reinforces entity kinds and the bend_radius semantic for tubes, but does not cover doc or name, so it neither needs to compensate heavily nor adds much beyond the schema.

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

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

States a specific verb+resource (create a 3D sketch) and enumerates the supported entity types (lines, polylines with bend_radius, splines, 3-point arcs) plus the unit convention (model mm). It also implicitly separates itself from sw_create_sketch by pairing with 3D consumers such as sw_sweep and sw_structural_member.

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?

Concrete downstream use cases are given ('sweep paths for tubes, cable routes, frame layouts for sw_structural_member'), which tells the agent where this tool fits in a workflow. It stops short of naming the 2D alternative (sw_create_sketch) or stating when not to use it, so no exclusion guidance.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-read-only but non-destructive operation. The description adds the creation modes and target use cases, but does not clarify what happens if both or neither of axis/face_point are provided. With annotations covering the safety profile, this is adequate but not rich.

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

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

The description is a single front-loaded sentence with no wasted words. It conveys the axis modes and the main usage context efficiently.

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

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

The schema fully documents the four optional parameters, and annotations cover the safety profile, but the description does not explain the important interaction between axis and face_point or what happens when neither is supplied. For a creation tool with no output schema and zero required parameters, that missing behavioral detail leaves a meaningful gap.

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

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

Schema description coverage is 100%, so the schema already documents doc, axis, name, and face_point. The description adds high-level mode context by mentioning X/Y/Z versus a cylindrical face, but does not add syntax, exclusivity rules, or default behavior beyond what the schema already provides.

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

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

The description identifies the resource precisely: a reference axis created either along X/Y/Z or through a cylindrical face. It distinguishes this from related creation tools like sw_create_plane by specifying the axis-specific geometry and use cases. The only slight gap is that it does not explicitly start with a verb like 'Creates', though the tool name and noun phrase make the action clear.

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

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

The description gives clear usage context: 'for patterns, angled planes and mates'. That tells an agent when this tool is relevant, though it does not explicitly name alternatives or exclusions versus sibling tools such as sw_create_plane.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-destructive mutation. The description adds useful ordering context around sw_set_properties and sw_export, but it does not say whether a new drawing document is created, whether an existing drawing is overwritten, or where the result is saved. With annotations covering the safety profile, a 3 is appropriate.

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

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

Two short sentences with the output composition front-loaded and the prerequisite/follow-up guidance second. There is no filler. The first sentence is a fragment ('A drawing of...'), which is slightly less direct than an explicit verb-first statement.

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

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

For an 8-parameter creation tool with no output schema, the description gives the essential workflow but omits important context: whether a new drawing file is created, how existing drawings are handled, and what the caller gets back. It is adequate to initiate a call but not 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 75%, with enum values and descriptions for bom, paper, scale, views, standard, and dimensions already in the schema. The description mentions the concepts behind those features (views, isometric, dimensions, BOM) but adds no syntax, defaults, or behavioral detail beyond the schema. Baseline 3 is correct here.

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 what is produced: a drawing containing three standard views, an isometric view, dimensions, and a BOM for a saved part/assembly. This is clear enough to distinguish it from export or view-insertion siblings, though it never uses an explicit verb like 'create' and doesn't explicitly contrast with sw_add_drawing_view.

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

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

It provides concrete workflow guidance: fill the title block with sw_set_properties on the model first, then export with sw_export. This tells the agent the prerequisites and the downstream step. It does not explicitly state when not to use this tool or how it relates to sw_add_drawing_view, so it stops short of a 5.

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

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

Annotations already classify this as a non-destructive mutation (readOnlyHint=false, destructiveHint=false). The description adds behavioral detail by disclosing the two construction methods (parallel offset vs. rotated about an axis), which is useful context beyond annotations. However, it omits side effects, reversibility, and what exactly is created, so it's adequate but not rich.

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

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

The description is a single, front-loaded sentence that efficiently conveys the core purpose and the two modes. It contains no filler, though a bit more structure (e.g., separating the two modes) could improve readability.

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

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

Given the tool has seven parameters, no required fields, complete schema coverage, and annotations covering safety, the description covers the essentials. However, it doesn't mention document context, return behavior, or mutual exclusivity of offset vs. angle, leaving some gaps for an agent to infer.

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

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

Schema description coverage is 100%, so the schema fully documents all seven parameters. The description mentions offsets and axes in passing but adds no additional semantic clarity beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description states a specific resource (reference plane) and its two construction modes, clearly distinguishing it from siblings like sw_create_axis or sw_create_sketch. It doesn't explicitly name alternatives, so it falls short of a 5.

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

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

The description explains what the tool does but gives no guidance on when to use it versus alternatives, nor any prerequisites or exclusions. It merely restates the operation's two modes, leaving usage context implicit.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is known; the description adds that pattern, mirror and driving dimensions can be baked into the entity definitions. It does not disclose whether each call creates a fresh sketch feature or appends to an existing one, nor whether dimension names persist, which matters for a non-read-only 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?

Two tight sentences with the capability list front-loaded and the parametric-feature note second; no filler. The second sentence is slightly compressed into one clause covering three distinct concerns, but overall it is efficiently sized.

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

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

For a tool with 14 entity variants and 7 parameters, the description covers entity variety well but leaves the agent to discover plane/face selection, coordinate-mode switching and fully-defined behavior from the schema. With no output schema and modest annotation context, a bit more setup/placement guidance would materially help first-call correctness.

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 86%, so the schema already documents coordinates, dimension naming, patterns and mirroring in detail. The description only echoes the pattern/mirror/dimension trio at a high level and says nothing about `plane`, `fully_define`, `model_coordinates`, or `doc`, so it adds little beyond the schema.

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

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

Specific verb + resource ("Create a 2D sketch") followed by an exhaustive enumeration of supported entity kinds, which tells an agent exactly what geometry this tool covers. The word "2D" implicitly separates it from sw_create_3d_sketch, but 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?

Usage context is implied by the entity list and the note that dimensions make the model later editable via sw_set_dimension, but there is no explicit when/when-not guidance. Nothing tells the agent when to prefer sw_create_3d_sketch, sw_generate_wing (vs an airfoil entity), or the dedicated pattern tools over the inline `pattern` field, nor when to pick `plane` versus `face_point`.

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

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

Annotations already declare this is a non-read-only, non-destructive mutation, so the safety profile is covered. The description adds little behavioral context beyond "copies" — it does not state that it creates a new feature in the document, requires a curve sketch or edge, or how the original features are treated.

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

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

The description is a single front-loaded sentence with zero wasted words, and the parenthetical examples earn their place by clarifying the operation. There are no structural issues or redundancy.

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

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

For an 8-parameter mutation tool with no output schema, the description is too sparse. It omits how to specify the curve, what the required features and count parameters mean, and what happens to the document when the pattern is created.

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 75%, with most parameters such as doc, name, spacing, curve_sketch, align_to_curve, and curve_edge_point documented in the schema. The description adds the curve-pattern concept but does not explain the required features or count parameters, so it adds only marginal meaning beyond the schema.

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

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

The description names a specific verb ("Copies") and resource/scope ("along a curve"), with concrete examples like rivets along an edge and vents along an arc. It distinguishes the operation from linear or circular patterns implicitly through "curve," but does not explicitly contrast those siblings.

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

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

The examples imply appropriate use cases for a curve-driven pattern, but there is no explicit guidance on when to choose this over sw_linear_pattern, sw_circular_pattern, or sw_sketch_pattern. Alternatives and exclusions are left 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?

The description adds functional context (material removal) that complements the safety annotations. Since behavioral traits like input/output limits are not detailed, a neutral score is appropriate, assuming the annotations are the primary source of behavioral 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 definition is highly concise, using a single, focused sentence to convey the entire functional scope of the tool.

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

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

As a summary, it is adequate but limited. Given the complex set of parameters (like 'depth', 'end_condition', 'thin_thickness'), a more complete definition would clarify which parameters are best suited for achieving the listed outcomes (pockets vs. slots).

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

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

With 78% schema coverage, the baseline score is 3. The description only adds high-level semantic meaning to the *results* of the operation (pockets/slots) and does not add unique meaning to the complex parameters themselves.

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 defines the action ('Remove material') and the mechanism ('extruding a sketch'). By listing outcomes like 'pockets, slots, plain holes', it provides better domain context than a simple 'extrude' function.

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 no guidance on when to use this tool versus its closely related sibling, 'sw_extrude'. It focuses solely on what the tool achieves without positioning it relative to 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?

The annotations already declare the safe read-only, non-destructive profile, so the description only needs to add context. It does add value by naming the returned fields, which matters because there is no output schema, but it is silent on what happens for non-weldment documents (empty result vs. error) and on whether it reads the active document by default.

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 fragment with zero padding. It is efficient, though the terseness borders on under-specification rather than optimal density.

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 one optional param and no output schema, the description should carry more of the return-shape burden. It names the columns but not the grouping/nesting, units, or empty-state behavior, leaving real gaps for an agent interpreting results.

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

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

There is a single optional parameter, and the schema covers it at 100% with a clear 'defaults to the active document' note. The description adds nothing beyond that, which is the expected baseline when the schema already does the work.

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

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

The fragment identifies a specific resource, a weldment cut list, and enumerates the returned content (member groups, quantities, lengths, profiles). However, it has no verb and does not differentiate itself from nearby siblings such as sw_bill_of_materials or sw_weldment_profiles, so an agent must infer that this is the read/list counterpart.

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

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

There is no guidance on when to call this, versus sw_bill_of_materials or sw_list_bodies, and no stated prerequisite, such as the document needing to be a weldment assembly. The agent receives no exclusions or alternative routing.

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

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

Annotations declare destructiveHint=false, and the description adds real context beyond that boolean by explaining why: the removal is reversible via deleting the Delete Body feature. It still omits whether the tool works in assemblies or what happens if body_point misses a body.

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 zero waste; the verb, mechanism, and reversibility are all packed into one clause.

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?

Adequate but thin for a mutation tool with three parameters: it doesn't say which document contexts are supported or what a failed body selection looks like. With full schema coverage and annotations present, the remaining gaps are moderate rather than severe.

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 doc, name, and body_point (with mm units and 3-element constraint) are already documented. The description adds nothing about parameter meaning, so the baseline 3 applies.

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

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

States a specific verb (Remove) and resource (body) and explains the mechanism (Delete/Keep Body feature), which distinguishes it from siblings like sw_delete_feature and sw_move_copy_body. It lacks only an explicit contrast with those siblings.

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

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

Usage is implied rather than stated: the mention of a Delete/Keep Body feature signals part modeling with feature-based removal. There is no explicit when-to-use, no prerequisites, and no named alternative such as suppression or sw_delete_feature.

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

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

The description states this deletes a configuration, an irreversible mutation of design data, while annotations declare destructiveHint=false. That flagged mismatch leaves the agent with no reliable signal on reversibility, and the description adds nothing about what happens to features, drawings, or mates that reference the deleted configuration.

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 short sentence is front-loaded and wastes no words, but at this length it is under-specified rather than concise. The single clause cannot carry the preconditions and consequences an agent needs 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?

For a mutation tool with no output schema and questionable annotation coverage, the description should explain the active-configuration precondition, whether the active config must be switched first, and what happens to dependent features. None of that is present, leaving the definition materially incomplete.

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

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

Schema description coverage is only 50%: the `doc` parameter is documented in the schema, but `name` — the sole required parameter — has no description in either the schema or the tool description. The description does not clarify that `name` is the configuration name or whether it must match exactly.

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

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

The description gives a specific verb and resource (delete a configuration) plus a scope constraint (non-active), which is clear and distinct from siblings like sw_delete_feature or sw_delete_body. It stops short of naming which sibling to use instead when the configuration is active.

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 '(non-active)' implies the tool fails or is inappropriate for the active configuration, but the description never states the precondition explicitly nor routes the agent to sw_activate_configuration or sw_list_configurations first. No when-not-to-use guidance is given.

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

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

The description says 'Delete,' a destructive operation, while the annotations declare destructiveHint=false. This is a direct contradiction of the structured safety signal. The description adds no compensating context about what the deletion affects or whether it 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?

A single, front-loaded sentence with no wasted words. It is slightly under-specified rather than overly verbose, but conciseness itself is strong.

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 deletion tool with an annotation contradiction, no output schema, and one undocumented parameter, the description is too thin. It doesn't clarify consequences, permissions, or what happens to dependent references, leaving an agent without the context needed to invoke it safely.

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

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

Schema coverage is 50%, so the description must compensate for one undocumented parameter. It does explain that 'index' refers to an index obtained from sw_list_equations, which is valuable, but the 'doc' parameter is only described in the schema and not addressed here. Baseline 3 fits given partial compensation.

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 equation by its index') and ties the index source to a named sibling, sw_list_equations. It is distinguishable from generic delete tools, though it doesn't explicitly contrast with sw_delete_feature or other equation tools like sw_add_equation.

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 'by its index from sw_list_equations' implies the workflow of listing equations first, which is useful. However, there is no explicit when-to-use guidance, no mention of prerequisites, and no statement about when not to use this tool versus 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?

Annotations declare readOnlyHint=false and destructiveHint=false, and the description explains why the low destructiveness is credible: only features the server itself created this session can be removed, everything else is merely suppressed. That is genuine context beyond the annotations, though nothing is said about reversibility (e.g. whether sw_undo can restore the deletion) or what the call returns.

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

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

A single sentence with no filler, and the most decision-relevant constraint (session-scoped deletion only) is placed where the agent will read it first.

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

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

No output schema exists, so the description should at minimum hint at the result of the call and clarify the required 'feature' identifier; it does neither. The scope constraint is well handled, leaving a mutation tool that is adequately but not fully specified.

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

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

Schema coverage is only 50%: 'doc' is documented in the schema, but the required 'feature' parameter carries no description anywhere. The description does not compensate by explaining whether 'feature' is a name, index, or tree path, which is exactly the ambiguity an agent will hit when calling this tool.

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

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

States a specific verb and resource ('Delete a feature') plus a meaningful scope restriction ('this server created in this session'), so the agent knows exactly what class of object is affected. The parenthetical about suppression implicitly separates it from sw_set_suppression and sw_delete_body, but neither 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 when-to-use condition (feature was created by this server in this session) and a when-not signal ('others can only be suppressed'), which tells the agent to fall back to suppression for pre-existing features. The alternative tool is only implied by the word 'suppressed', not named.

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

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

Annotations already declare this is a non-read-only, non-destructive mutation, and the description adds nothing beyond that safety profile. It doesn't say a new feature is created in the feature tree, that the target document must be active or specified via 'doc', or what happens on invalid geometry.

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 the purpose followed by an immediately useful use-case gloss. It is efficient, though the parenthetical substitutes for rather than supplements behavioral detail.

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

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

For a 6-parameter feature-creation tool with no output schema, the schema covers most parameters well, but the description leaves gaps around the 'flip' direction parameter and the document/feature-tree effects of the operation. It is minimally sufficient rather than complete.

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

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

Schema description coverage is 83%, so the schema already explains angle range, face_points, neutral_face_point, and name. The description contributes no parameter-level meaning (e.g. what 'flip' toggles), so baseline 3 is appropriate.

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

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

States a specific verb+resource ('Add draft to faces') and clarifies the domain purpose with the parenthetical about moulding/casting/3D-print removal. It is unambiguous what the tool does, though no sibling is named because no other draft tool exists.

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 hints at when this applies (moulding, casting, print removal), which is implied usage context. There are no explicit when-not conditions, prerequisites (e.g. an open document with solid bodies), or named alternatives among the many feature tools like sw_shell or sw_thicken.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, and the description does not contradict that, so no contradiction flag. However, for a mutation tool the description adds nothing beyond the title: it does not say whether existing exploded states are overwritten, whether the operation is reversible via sw_collapse, or that the model's component positions change in the view.

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

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

It is a single short sentence with no padding, which is structurally clean, but the brevity comes from under-specification rather than economy. There is no front-loaded verb or scope statement to anchor the agent.

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

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

Given a mutation tool with no output schema, an undocumented 'distance' parameter, and an obvious inverse sibling (sw_collapse), the description is not complete enough: it omits reversibility, units, and preconditions. An agent can invoke it with defaults but cannot predict the resulting geometry.

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?

Only the 'doc' parameter is documented in the schema; 'distance' (default 50, exclusiveMinimum 0) has no description and no units, and the tool description never mentions parameters at all. With 50% schema coverage the description should compensate, but it provides no information on what 'distance' controls (spacing between components?) or its unit of measure.

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

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

The phrase 'Automatic exploded view of the assembly' conveys the resource and rough effect, but it is a noun phrase without a clear verb and never distinguishes itself from the obvious sibling sw_collapse, which is the inverse operation. An agent can guess the intent but must infer whether it creates, applies, or returns an exploded view.

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 sw_collapse, no prerequisites (does it require an open assembly, an active configuration?), and no mention of what state the assembly must be in. The description offers zero routing information.

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

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

Annotations already flag this as non-read-only and destructive (it writes files), so the bar is lower, but the description adds essentially no behavioral context beyond the format list. It omits that output must land in an allowed folder, that overwrite triggers a user confirmation, and what the destination defaulting behavior is — all of which matter for a file-writing 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?

One short sentence, front-loaded with the verb and resource, zero filler. However, the terseness is partly a symptom of under-specification rather than disciplined economy.

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

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

With five parameters, no output schema, and a destructive write operation, the description leaves key questions unanswered: where the file goes, what happens on failure, whether the document must be open first, and how this differs from batch export. For a mutation tool with no return-value documentation, more was 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 80% and the 'file_format' enum is self-documenting; the description merely echoes the format enum values. The format-name mapping (e.g. Parasolid, DXF/DWG, PNG/JPG) confirms which enum entry corresponds to which CAD format, which is mildly useful, but nothing is said about path, doc, or stl_quality semantics. Baseline 3 fits.

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?

A specific verb (export) plus the resource ('a copy') plus the full format list makes the intent unmistakable. It does not explicitly distinguish itself from close siblings like sw_batch_export, sw_export_flat_pattern, or sw_save, so it stops short of a 5.

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

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

The description never says when this tool should be chosen over sw_batch_export (multiple files), sw_export_flat_pattern (sheet metal), or sw_screenshot/sw_print_check. No prerequisites, no exclusions, no conditions are given; the agent must infer routing from the format list alone.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the write/destructive nature is covered structurally. The description adds nothing about what is destroyed — presumably an existing target file — nor about write permissions, directory creation, or what the tool returns on success. For a file-writing operation the description is silent on all behavior beyond format.

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

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

A single front-loaded sentence with zero filler. It is efficient, though the terseness comes at the cost of the usability details noted elsewhere — it is concise rather than padded.

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

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

With no output schema and no annotations beyond the safety flags, the description should say what happens on success (file written where? path returned?), that the part must be sheet metal, and what bend_lines controls. None of that is present, so an agent calling this tool has significant unknowns.

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 75%, just under the threshold where the schema alone suffices; the undocumented parameter is bend_lines, which the description ignores entirely. It does implicitly clarify the path parameter by naming the accepted formats (DXF/DWG), but it says nothing about doc selection, overwrite semantics, or bend-line inclusion.

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

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

The description states the resource (flat pattern) and the output formats (DXF/DWG), which cleanly separates it from generic siblings like sw_export and sw_batch_export and from sw_flat_pattern, which presumably creates the flat pattern in-model. The verb 'export' is only implied by the tool name rather than written in the description, keeping it just short of a 5.

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

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

The phrase 'for laser / waterjet cutting' hints at the use case, but there is no explicit when-to-use, no prerequisites (e.g., the document must be a sheet-metal part with a flat pattern), and no routing to alternatives such as sw_export or sw_flat_pattern. An agent must infer the selection logic entirely.

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

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

Annotations already declare a non-read-only but non-destructive mutation. The description adds one genuine behavioral trait: thin_thickness turns open sketches into walls, which tells the agent open profiles are legal only in thin mode. It says nothing about failure modes for closed-profile-only conditions or whether a rebuild is needed.

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

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

Two short sentences, zero filler, and the primary action is front-loaded before the conditional thin-wall caveat. Nothing redundant with structured fields.

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

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

For a 10-parameter mutation tool with 90% schema coverage and no output schema, the description plus schema is nearly sufficient. The only real gap is what happens on failure or what a caller gets back, which is minor at this coverage level.

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 90%, so the schema already documents nearly every parameter including end_condition's enum and depth units. The description only adds meaning for thin_thickness (open sketches become walls); it says nothing extra about start_offset, second_depth, reverse, or how end_condition pairs with depth.

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

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

Specific verb + resource: 'Extrude a sketch into a solid (boss)'. The word 'boss' implies additive material, which implicitly distinguishes it from sw_cut_extrude, but the sibling is never named, so the agent must infer the routing.

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 via the object it acts on (a sketch) and the payoff (a solid). There is no explicit when-to-use guidance versus sw_revolve, sw_cut_extrude, sw_thicken or sw_shell, and no stated prerequisites such as requiring an active document or a closed profile.

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

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

Annotations declare readOnlyHint=false with destructiveHint=false, so the agent knows this mutates the model additively. Beyond that, the description says nothing about how the new feature is added to the tree, whether it can be undone/edited, or how failures are reported. The 'constant-radius' phrase adds one useful behavioral limit but not much else.

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. Its terseness is efficient, though it leaves little room for the usage and behavioral context a mutation tool needs.

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

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

This is a mutation tool with no output schema and thin annotations, yet the description omits error behavior, tree/feature implications, and edge-selection fallbacks that the schema hints at ('all' vs points). Adequate to identify the operation, insufficient to call it confidently in edge cases.

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 75%: doc, name, and edges are documented in the schema, but 'radius' has no schema description. The description's 'constant-radius' impliedly clarifies that radius is a single uniform value rather than a variable-radius input, modestly adding meaning. Baseline 3 is fair given the schema does most of the work.

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

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

Specific verb+resource ('round edges ... fillet') that an agent can distinguish from geometry siblings like sw_chamfer or sw_shell. The 'constant-radius' qualifier narrows the operation type. It doesn't explicitly name a sibling it differs from, so it stops short of a 5.

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

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

No guidance on when to use a fillet versus sw_chamfer, when it will fail (e.g., radius too large for the edge), or prerequisites such as needing an open document with edge geometry. The agent must infer all usage context from the name alone.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the agent knows this mutates something but is not destructive; the description adds nothing beyond that. It does not say whether the change is a transient view state or a persisted document setting, nor what happens when the active document is not a sheet metal part — a meaningful gap for a state-changing 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?

A single short sentence, front-loaded with the effect and immediately followed by the interpretation of the flag. Nothing is wasted or buried.

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, no-output-schema toggle this is close to adequate, but it omits the sheet-metal precondition, persistence semantics, and any routing to sw_export_flat_pattern. An agent can call it, but cannot be confident about side effects or failure modes.

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

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

Schema coverage is only 50%, with the flatten boolean having no schema description at all; the description supplies exactly that missing semantics by defining true=flat and false=folded. The doc parameter is already covered by the schema, so the description correctly spends its words on the undocumented 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?

Specific verb plus resource: toggles a sheet-metal part between flat and folded display, which is a distinct operation an agent can identify. It does not, however, distinguish itself from the sibling sw_export_flat_pattern, which produces the flat pattern as an output file rather than a view state.

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

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

The description states what the flag values mean but offers no when-to-use guidance, no prerequisites (e.g. the active document must be a sheet-metal part), and no mention of the obvious alternative sw_export_flat_pattern for actually producing flat-pattern geometry.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, and the description is consistent by noting a new document and cosmetic thread. However, it does not explain the save/overwrite side effects or what happens to existing files beyond what the schema already says.

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

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

It is a single tight sentence with no wasted words and the resource is front-loaded. It is grammatically a fragment and omits an explicit action, which slightly weakens structure.

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

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

Given the schema and destructive annotation, the description covers the core creation context. It is still thin for a document/file-producing tool and does not address routing to alternatives or return/side-effect details.

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

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

Schema description coverage is high at 80%, so the baseline is 3. The description adds ISO standard context but does not map those standards to the kind enum or clarify size/length semantics beyond the schema.

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

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

The description names a specific resource (metric fastener) and creation context (new document), with ISO standards that clarify the part family. It lacks an explicit verb and does not directly distinguish itself from sibling sw_insert_fastener, 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 no guidance on when to use this tool versus sw_insert_fastener or sw_generate_part. The only implied usage is that it produces a new fastener part, but no conditions or exclusions 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?

Annotations mark this as a mutating (readOnlyHint=false) but non-destructive operation; the description does not say that it creates a new solid body or feature in the document, whether it requires an existing document, or what happens to previously generated geometry. The '(0 size = point)' note duplicates what the schema already states for width/height rather than adding new behavior detail.

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 short sentence with the core concept front-loaded and no filler. It is efficient, though the parenthetical fragment makes it slightly telegraphic rather than self-contained.

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

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

No output schema exists, so the description would need to convey enough about the modeling result; it communicates the lofting concept but not the resulting body/feature, the hollow-shell behavior, or the two-station minimum. Rich schema field descriptions compensate substantially, keeping this at a minimum-viable level.

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

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

Schema description coverage is 100%, so the schema already documents stations, doc, name, and shell_thickness well, including the pointed-end semantics. The description's parenthetical restates the schema's own '0 makes a pointed end' note and adds nothing about shell_thickness or the station count minimum. Baseline 3 is appropriate.

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

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

The sentence names a concrete verb+resource (a fuselage/pod/nacelle lofted through ellipse, circle or rounded-rectangle frames), which is more specific than the sibling sw_loft and clearly distinct from sw_generate_wing or sw_generate_propeller. It does not explicitly name or contrast with any sibling, so it falls short of a 5.

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

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

There is no when-to-use guidance, no mention of when to prefer the generic sw_loft or sw_generate_part instead, and no prerequisites. The agent must infer from the word 'fuselage' alone that this is for aircraft-style body shapes.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the write-safe profile is already covered; the description usefully adds that the part is created "in a new document," which is real behavioral context an agent would otherwise not have. However, it does not say whether the new document becomes the active one, whether existing work is affected, or what the tool returns — gaps that matter for a document-creating mutation.

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

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

A single short sentence with no filler, but it is an elliptical fragment missing a verb, so the core action is not front-loaded. Efficiency is high; syntactic clarity is not.

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

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

The tool is low-complexity (2 params, one enum) and the params schema is self-documenting, so the description does not need to be long. Still, with no output schema and no statement of what the call produces or what units the parameters use, an agent must infer the post-call state.

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 `params` property carries a detailed per-kind key listing, while `kind` relies on its enum alone. The description adds only the notion that parameters have sensible defaults, which is useful but marginal beyond the schema; baseline 3 is appropriate since the schema does the heavy lifting.

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 sentence conveys the gist — generates a parametric part in a new document from a few parameters — but it is phrased as a noun fragment ("A typical part in a new document from a few parameters") rather than a verb+resource statement. Neither the `kind` options (l_bracket, flange, enclosure, motor_mount) nor the distinction from sibling generators (sw_generate_wing, sw_generate_propeller, sw_generate_fuselage, sw_generate_fastener) appear in the description, so an agent cannot tell from prose alone which generator to pick.

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

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

There is no explicit when-to-use guidance, no mention of the alternative generators, and no stated prerequisites. The only usage-adjacent hint is the parenthetical "all have sensible defaults," which implies params can be omitted but doesn't say when to supply them.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is covered. The description adds real geometric behavior not in structured fields — the twist law atan(P/2πr), the presence of a hub and bore, and that the result is aligned along Y with thrust in +Y — but says nothing about which document the feature lands in, whether an existing body is modified, or failure modes.

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

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

Two short clauses, front-loaded with the object being generated and the key geometric convention; no filler. It is terse to the point of omitting a verb, but nothing in it 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?

A 12-parameter generative/mutating tool with no output schema needs more: which document it writes into, whether units are uniformly mm, whether the blade profile comes from the airfoil or the chord params, and what the agent gets back. The orientation and formula help, but the definition is too thin for this parameter surface.

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%; blades, sections, tip_chord, root_chord, hub_length and hub_diameter carry no schema descriptions. The description partially compensates by tying pitch to radius in the twist formula and naming the hub and shaft bore, effectively explaining pitch, diameter, and shaft_diameter, but the chord/section/blade parameters remain opaque in both places.

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

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

The description identifies the resource precisely — a propeller with twisted blades, hub, and shaft bore — and even states the pitch-angle formula and orientation. It stops short of an explicit verb ('generates') and does no differentiation from siblings like sw_generate_wing or sw_generate_fuselage, but an agent can still tell what object is produced.

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 sw_generate_wing/sw_generate_fuselage/sw_generate_part, no prerequisites, and no mention of whether it requires an open part document or creates one. The only usage hint is structural (axis Y, thrust +Y), which is orientation, not selection criteria.

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

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

Annotations already cover the mutation profile (readOnly=false, destructive=false); the description adds real context beyond that: the wing is lofted and mirrored, and the call returns area, aspect ratio, MAC and neutral point. It also fixes the geometric convention (span along +X, flight direction +Z), which is not discoverable from annotations or schema. It does not state document prerequisites explicitly, keeping it just short of top marks.

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

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

Three tight sentences: what it builds first, then what it returns, then the orientation convention. Every clause carries information an agent needs and nothing is padded.

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 13-parameter, no-output-schema mutation tool, the description supplies the missing pieces: it enumerates the returned metrics (area, AR, MAC, neutral point) in lieu of an output schema and pins the coordinate conventions. With the schema already documenting per-parameter meaning, nothing essential 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 coverage is 85%, so the baseline is 3; the description earns an extra point by specifying axis conventions (span on +X, flight on +Z) that no parameter description conveys, and by framing taper/twist/sweep/dihedral as the wing-shaping inputs. It still leaves units and the meaning of sections/incidence 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 ('generate a complete wing') plus the exact composition (blended airfoil sections with taper, sweep, dihedral, twist, lofted and mirrored). This clearly separates it from sibling generators like sw_generate_fuselage, sw_generate_propeller and the manual sw_loft/sw_sweep path.

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?

'A complete wing in one call' implies when to prefer this over assembling lofts and mirrors manually, but no sibling is named and there are no explicit exclusions or preconditions (e.g. requires an open document). Usage is inferred rather than stated.

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

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

The annotations already provide strong safety guarantees (readOnlyHint: true, destructiveHint: false). The description adds useful operational context by confirming that the properties are read within the scope of a specific document and configuration.

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 maximally concise, consisting of a single, high-impact sentence that immediately tells the user the tool's function.

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?

Despite having two contextual parameters (document and configuration), the description remains extremely vague. Without an output schema, the agent is left to infer what kind of 'properties' are returned or if there are any limitations on the data scope.

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

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

With only 50% schema description coverage, the description adds marginal value by clarifying that the 'doc' parameter can be a path or title and defaults to the active document. However, since the coverage is low, the description cannot fully compensate for the missing documentation on the other 50% of 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 the action ('Read custom properties'), but it lacks differentiation from the extensive list of similar sibling tools (e.g., sw_set_properties, sw_mass_properties). It is clear what it does, but not distinctly how it fits into the overall tool ecosystem.

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 definition provides no guidance on when to use this tool versus other available tools. There is no mention of prerequisites, limitations, or how to distinguish 'custom' properties from other available property operations.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds genuinely useful diagnostic semantics — that zero-volume bodies indicate a kernel problem and that it should be restarted — which the annotations do not convey.

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 names the check and immediately pairs the actionable symptom with the remedy. 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 no-parameter, read-only diagnostic, the description covers what is checked and how to interpret the key failure signal. It does not say what a success response looks like (boolean vs. status object), but with no output schema present this is a minor gap rather than a blocking one.

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

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

The tool has zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 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 ('Check') and resource ('SolidWorks' and 'its geometry kernel'), plus what a failure looks like. It does not differentiate itself from nearby siblings like sw_status or sw_connect, 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?

Usage is only implied: the parenthetical about zero-volume bodies and restarting hints at 'call this when something seems wrong.' There is no explicit statement of when to prefer this over sw_status or sw_connect, nor any preconditions.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is known, but the description adds nothing beyond that: no note that the tool mutates the active document, no mention of what happens on invalid input or whether a partial feature can be left behind, and no confirmation of the returned result. For a feature-creating mutation, this leaves behavior essentially undisclosed.

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 clause with no filler or repetition. It is efficient, though the terseness is a symptom of under-specification rather than disciplined brevity, which is penalized in other dimensions rather than here.

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

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

This is a 9-parameter mutation tool with no output schema and thin schema documentation, so the description should carry real weight, but it does not mention prerequisites (active document, sketch containing exactly one circle), the result of the call, or how the geometry options interact. An agent could not reliably call it correctly from this definition alone.

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

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

Schema description coverage is only 33%: doc, name, and sketch are documented, but pitch, revolutions, reverse, clockwise, start_angle, and taper_angle carry no descriptive text, only numeric constraints. The description compensates with nothing about parameter meaning, units, or direction/taper interaction, so six of nine parameters remain semantically opaque.

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 resource, the helix curve, and gives concrete applications (springs, coils, augers, threads), which makes the geometry it produces unambiguous. It never states an explicit verb, so 'creates a helix feature' must be inferred, and it does not distinguish itself from sibling sw_spring, which also covers springs.

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 use cases ('path for springs, coils, augers, threads') imply context but give no when-to-use rules, no prerequisites such as an open document with a valid sketch, and no direction toward alternatives. An agent must guess whether sw_spring is preferable for a spring rather than calling sw_helix directly.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds only the sibling routing and does not state that this creates a feature in the active document, what happens to existing geometry, or the implications of the face_point/positions requirements.

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 a parenthetical routing hint; nothing is wasted and the alternative is placed immediately after the statement of purpose.

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

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

For an 11-parameter creation tool with 36% schema coverage and no output schema, this description is too thin. It should at minimum explain that hole_type=counterbore/countersink activates the extra diameter/depth/angle parameters, which is the main source of invocation error here.

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 36%, so the description needs to compensate — but it says nothing about diameter, hole_type (simple/counterbore/countersink), counterbore_diameter/depth, countersink_diameter/angle, or how those conditional groups interact. The six undocumented parameters get no support from 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?

Clear verb+resource: 'Plain holes of any diameter' and it distinguishes itself from the sibling sw_hole_wizard explicitly. However, 'plain' understates scope since the schema's hole_type enum includes counterbore and countersink, so an agent could wrongly assume simpler geometry than the tool supports.

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

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

Explicitly routes standard fastener holes and threads to sw_hole_wizard, which is exactly the when-not guidance needed against the one close sibling. It stops short of saying when to pick counterbore/countersink via hole_type, but the primary alternative is named.

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

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

Annotations already say readOnlyHint=false and destructiveHint=false, so the safety profile is minimally covered. The description adds only the supported hole categories and does not explain that this creates a feature in the active document, what happens to existing geometry, undo behavior, or failure 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?

A single front-loaded sentence with no wasted text. It is concise, though the extreme brevity leaves the definition under-specified for a nine-parameter mutation tool.

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

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

The tool has nine parameters, no output schema, and basic annotations. The description does not explain required positions/size behavior, standards, through-vs-depth semantics, or what the tool returns, so it is not complete enough for confident 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 67%, so several parameters still need description-level clarification. The description merely echoes the hole_type choices already exposed by the schema and adds no meaning for size, depth, thread_depth, standard, positions, or cosmetic_thread.

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

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

Names the resource and the supported hole variants: tapped/threaded, counterbore, countersink, and clearance. The action is only implied by "Hole Wizard" rather than stated with an explicit verb, and it does not distinguish this from sibling tools such as sw_hole or sw_thread.

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?

Lists the hole styles but gives no guidance on when to use this wizard versus sw_hole, sw_thread, sw_cosmetic_thread, or sw_insert_fastener. No exclusions or decision criteria are provided.

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

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

Annotations already declare this a non-read-only, non-destructive mutation, so the description need only add context. It adds almost none: nothing about what happens if the active document is a part rather than an assembly, whether the source file is referenced/linked versus copied, or whether the operation is reversible via sw_undo.

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 zero redundancy. It is efficient, though arguably undersized rather than oversized for a five-parameter mutation tool.

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

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

No output schema exists, so the description should carry more of the burden. For a mutation tool with five parameters and only generic annotations, it omits the active-document precondition, error behavior, and the result of the operation (e.g., a new component entry visible via sw_list_components).

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%, with all five parameters fully documented in the input schema (path, doc, fixed, position in model mm, configuration). The description adds no clarification or constraints beyond that schema, so the baseline 3 applies.

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

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

Names a specific verb ('Insert') and a specific resource ('saved part or sub-assembly') plus the target ('active assembly'), which is far more precise than the bare tool name. It stops short of differentiating from the closest sibling, sw_insert_fastener, which also inserts a component-like object.

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 'into the active assembly' implies the prerequisite that an assembly document must be active, but the description never states when to choose this over sw_insert_fastener, sw_new_document, or sw_open, nor any exclusions or failure conditions.

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

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

Annotations already declare this is a mutating but non-destructive operation, so the description is not on the hook for the safety profile. It does add real behavioral context beyond the annotations – the fastener is created once and reused, and a mate to the hole is created as part of the same call. It does not say what happens if the mate fails, whether repeated calls duplicate components, or whether the new component shows up in sw_list_components.

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

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

A single sentence with zero filler, front-loading the action and resource before the placement/mate details. Nothing repeats the title or restates the schema.

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

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

For a 7-parameter mutation tool with no output schema, the definition covers what it does and its two side effects, and annotations cover the safety profile. It is still thin on outcome details – what the call returns, whether it requires an active assembly, and how it interacts with sw_generate_fastener, which is its closest sibling and a likely source of wrong-tool selection.

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 86%, so the schema already explains size format, length semantics, and the meaning of hole_face_point, seat_face_point, flip, and doc. The description adds nothing about parameters beyond loosely referring to 'a hole' (mapping to hole_face_point) and note that it must be mated. Baseline 3 is appropriate when the schema carries the parameter burden.

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 (insert) and resource (standard metric fastener), and adds scope detail that matters: it is placed into the assembly and mated to a hole. The parenthetical '(generated once, reused)' obliquely distinguishes this from the sibling sw_generate_fastener, but it never names that sibling, so an agent comparing the two still has to infer the difference.

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 'generated once, reused' implies this is the right tool when a reusable library fastener is wanted rather than freshly generated geometry, which is useful implied guidance. However, there is no explicit when-to-use statement, no exclusion, and no mention of prerequisites such as an open assembly document or the relationship to sw_insert_component and sw_add_mate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds that the result includes overlap volume magnitudes and that touching contact is a separate, opt-out category — useful context. It does not describe the return shape (e.g., pairs of components with volumes, or whether an empty result is possible), leaving a gap despite the presence of no output schema.

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

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

A single front-loaded sentence with no filler. The overlap-volume outcome and the optional touching behavior are both conveyed economically.

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-only, two-parameter query tool with no output schema, the description covers purpose and the optional mode but does not tell the agent what comes back (component pairs, volume units, empty-result behavior). Enough to call it correctly, but not enough to interpret results confidently.

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

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

Schema coverage is 50%: 'doc' is documented in the schema itself, while 'treat_touching_as_interference' has no schema description. The description's phrase 'optionally touching ones' supplies the meaning of that otherwise undocumented boolean, compensating for the coverage gap. It is still implicit rather than stating the default or the exact effect.

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 concrete verb and resource: find overlapping components and report the overlap volume. That is clearly distinct from nearby siblings like sw_measure or sw_check_requirements, though the description never names those alternatives, so the differentiation is implicit rather than explicit.

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

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

The parenthetical 'optionally touching ones' signals that touching contacts are excluded by default, which hints at how to use it. There is no explicit statement of when to prefer this over sw_measure or sw_check_requirements, nor any prerequisite or context about when interference checking is appropriate.

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

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

The readOnlyHint=true and destructiveHint=false annotations already establish that this is a safe read operation. The description adds useful context by saying it exposes the journal file path and last entries, but it does not cover pagination behavior, entry ordering, or return format details beyond that.

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

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

The description is a single compact sentence with no wasted wording, and the key scope ('model-changing operations in this session') is front-loaded. It is appropriately concise for a simple read-only retrieval tool.

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

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

For a one-parameter, read-only tool with no output schema, the description gives a basic idea of what is returned: a journal file path and recent entries. However, it does not describe the return structure, whether entries are chronological, or how the optional 'last' parameter affects the result, leaving some ambiguity for an agent.

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

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

The schema has one optional parameter, 'last', with 0% description coverage. The phrase 'the last entries' hints that the parameter controls how many recent journal entries are returned, but it does not explicitly explain the parameter's meaning, and the schema's default and maximum values are left to speak for themselves.

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

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

The description identifies a specific resource: the journal of model-changing operations for the current session, including the file path and recent entries. It is clear enough to distinguish it from most sibling tools, but it omits an explicit action verb and does not differentiate it from sw_replay_journal.

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

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

There is no guidance on when to use this tool versus alternatives. The sibling list includes sw_replay_journal, which is closely related, but the description does not mention when to inspect the journal versus replay it, nor any 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?

Annotations already declare a non-read-only, non-destructive mutation, so the safety profile is covered. The description adds no behavioral detail the annotations don't: nothing about how a second direction turns a row into a grid, what happens with large counts, whether the seed instance counts, or that geometry is added to the model.

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 zero filler. However, at this terseness for a 9-parameter mutation tool it under-serves the reader rather than being efficiently complete.

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

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

For a 9-parameter, low-coverage, no-output-schema tool, the description omits the grid/second-direction semantics, the meaning of count vs count2, and any feature-selection guidance. The essentials for calling it correctly are not present.

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

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

Schema coverage is only 33%, so the description must compensate and it explains none of the parameters. Key fields like count2, spacing, spacing2, direction2 and features have no schema description and no mention here, leaving the grid behavior (second direction/spacing) entirely undocumented.

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

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

States a specific verb+resource ('Repeat features') and adds scope detail ('in a row or grid') with concrete examples (ribs, holes, slots, frame members). The 'row or grid' phrasing implicitly separates it from sw_circular_pattern and sw_sketch_pattern, but no sibling is named, 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 statement of when to choose this over the many sibling pattern/mirror tools (sw_circular_pattern, sw_sketch_pattern, sw_curve_pattern, sw_mirror). Usage is only inferable from the word 'linear' in the name; no prerequisites, no exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description contributes real value by disclosing the return payload (bounding boxes plus a pick point per body), which is not in any structured field since there is no output schema. However, it says nothing about scope — whether hidden, suppressed, or component bodies are included.

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

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

It is a single short fragment with zero padding, so nothing is wasted. But it is a sentence fragment rather than a front-loaded statement of purpose, and its brevity comes at the cost of omitting scope and behavior.

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

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

With no output schema, the description must describe the return value, and it does so at a high level — bounding box and pick point per body. Gaps remain: units of the bounding box, coordinate frame, and whether the call requires an active document or fails without one.

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

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

The single optional 'doc' parameter is fully documented in the schema, including the default-to-active-document behavior, so schema coverage is 100%. The description adds nothing about the parameter, which is acceptable at this coverage level but not a contribution.

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

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

The phrase 'Solid and surface bodies with bounding boxes and a pick point for each' describes the resource being returned, and the tool name makes the listing intent clear, but the description itself never states a verb like 'lists' or 'enumerates'. It is distinguishable from siblings such as sw_list_features or sw_list_components only by the noun 'bodies', which is doing all the differentiation work.

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

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

There is no indication of when to call this versus alternatives (sw_mass_properties, sw_measure, sw_list_entities) or what preconditions apply, such as needing an open document. The agent must infer all routing from the tool name alone.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a little context by scoping results to 'top-level' components and mentioning position and state, but says nothing about return structure, ordering, or behavior with a missing/inactive document.

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

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

It is short and front-loaded, but it is an under-specified noun phrase rather than a complete sentence with a verb. Brevity here reflects minimal content rather than disciplined editing.

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

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

For a tool with no output schema, the description should convey what the returned component entries look like and how 'state' is represented. It gestures at 'position and state' but leaves the return shape largely undefined, which is a meaningful gap for an agent consuming the output.