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

Annotations already declare that this is a non-read-only, idempotent, non-destructive operation. The description adds the important context that activation targets an existing configuration in the active part or assembly, but it does not describe failure behavior when the name is missing or the document has no matching 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?

It is a single front-loaded sentence with no filler. Every phrase contributes to action, target, or 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?

For a simple one-parameter activation tool with an output schema and rich annotations, the description covers the core action and document scope. It could be slightly more complete by noting what happens when no matching configuration exists.

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

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

Schema description coverage is 0%, so the schema only says the parameter is a string named 'name'. The description compensates partially by clarifying that 'name' refers to an existing configuration to activate, but it does not specify matching rules or formatting.

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: activate an existing configuration. It adds useful scope ('by name in the active part or assembly') but does not explicitly contrast with siblings such as list_configurations or add_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?

Usage is implied: use it to activate an existing configuration in the active document. However, it gives no explicit when-to-use guidance, prerequisites, or alternatives for listing or adding configurations.

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 readOnly=false, destructive=false, idempotent=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: the new configuration is automatically activated. It is silent on duplicate-name handling (error vs. auto-suffix) and on the non-idempotent consequence of calling twice, which is the main risk an agent needs to know.

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 creation action and the activation side effect both land immediately. It is efficient, though a second short clause on naming/duplicate behavior would have earned its place.

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

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

An output schema exists, so return values need no explanation, and annotations cover the mutation profile. But with three undocumented parameters at 0% schema coverage and no statement about duplicate names or document-state preconditions, an agent still lacks what it needs to call this confidently.

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

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

Schema description coverage is 0% — the schema only supplies titles, no semantics for name, comment, or description. The tool description does not compensate at all: it never mentions the name parameter's requiredness or naming constraints, nor that comment and description are optional free-text metadata.

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 (adds) and resource (a new configuration) plus the scope (active part or assembly document), and adds that the new configuration becomes active. This clearly separates it from activate_configuration (switches existing) and list_configurations (reads), though it does not name 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 usage is implied: create-and-activate a configuration in the currently active document. There is no explicit guidance on prerequisites (must a document be open?), on what to do instead when the configuration already exists, or on when to prefer activate_configuration over this tool.

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

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

Annotations already declare a non-readonly, non-idempotent, non-destructive mutation. The description adds context beyond them by disclosing that the call triggers a rebuild — a meaningful side effect on the model — and by spelling out the required string syntax. It stops short of saying what happens on a duplicate name or an invalid expression.

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

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

The action and its side effect lead, followed by two compact examples that each teach a distinct mode. Every sentence earns its place 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?

With an output schema present, return values need no explanation, and the description covers syntax, semantics and the rebuild side effect for a single-parameter mutation. It could be stronger by noting failure modes (bad syntax, duplicate variable name) that an agent should anticipate.

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

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

Schema description coverage is 0%, so the description must carry the single parameter, and it largely does: double-quoted names, the two accepted expression shapes, and the unit-defaulting rule for bare numbers. Only edge details (escaping, explicit units, multiple statements) are left implicit.

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 ('Adds a global variable or an equation'), with the two supported modes spelled out and each illustrated by a concrete example. An agent can immediately tell this apart from get_equations and delete_equation in the sibling list.

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

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

The description distinguishes the two forms of input (global variable vs. dimension-driving equation), which is useful context, but it never states when to reach for this tool versus set_dimension or add_sketch_dimension, nor any preconditions (e.g., an open document). Usage is implied rather than guided.

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 establish that this is a non-read-only, non-idempotent, non-destructive mutation in the active assembly. The description adds useful context about supported mate types and coordinate/name-based entity selection, but does not mention over-constraint behavior, failure modes, or persistence of the new mate.

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

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

The purpose is front-loaded in the first sentence, followed by precise entity-specification guidance and a compact supported-type list. There is no redundant or filler 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?

Output schema existence removes the need to explain return values, and annotations cover safety characteristics. However, for a nine-parameter CAD mating tool with low schema coverage, the description still omits key semantics for alignment, flip, and how entity name and point parameters interact.

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 22%, so the description must compensate. It explains entity selection via 3D assembly-coordinate points or qualified entity names and lists mate types, but leaves alignment, flip, and the relationship between point and name parameters unexplained.

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

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

States a specific verb and resource: adds a geometric mate constraint between two components in the active assembly. This clearly differentiates it from sketch relations, assembly creation, and component insertion in the sibling list.

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

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

Implies when to use it by describing the two entity-specification modes and supported mate types, but gives no explicit when-not-to-use guidance or comparison to alternatives such as add_sketch_relation.

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 mutation, idempotency, and open-world behavior. The description adds useful behavior beyond that: the dimension is 'driving', value is in mm or degrees for angles, and text placement defaults next to the entity. It does not discuss failure cases such as over-constraining the sketch.

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

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

The description is compact and front-loaded with the core action, then structured by coordinate groups. Every sentence contributes semantic detail without 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 7-parameter CAD mutation tool with an output schema and annotations, the description supplies the essential coordinate semantics, units, and default behavior. It is nearly complete, though it omits edge cases like conflicting constraints or what happens if no sketch is open.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains x,y as a point on the entity, x2,y2 as an optional second entity for distance/angle dimensions, value units, and text_x,text_y as optional text placement with a default. This compensates well for the bare schema titles.

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: adds a driving dimension to the open sketch. It also explains the value unit. It does not explicitly differentiate from the sibling set_dimension or add_sketch_relation, 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?

Clear context is given: the sketch must be open, and one-entity versus two-entity modes are described. It does not say when to use this tool instead of set_dimension or add_sketch_relation, so no exclusions or alternatives 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 the mutation profile (readOnly=false, idempotent=false, destructive=false), so the description only needs to add context; it contributes the 'open sketch' prerequisite and the point-per-entity correspondence. It says nothing about failure behaviour (e.g. an over-constrained or already-defined sketch), whether duplicates are rejected, or what side effects the relation has on the sketch's degrees of freedom.

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

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

The core action is front-loaded in one sentence, followed by two compact parameter notes keyed to their argument names. Dense but efficient; no filler, though the vertex sentence packs several ideas into one parenthetical that could be split for readability.

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

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

An output schema exists, so return values need not be explained. However, this is a mutation tool with three parameters and zero schema description coverage, and the description omits the mapping of entity count to point count per relation and any error/constraint behaviour, leaving real gaps for correct invocation.

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

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

Schema coverage is 0%, so the description carries the burden; it does explain points (one sketch-coordinate point per involved entity) and vertex (one boolean flag per point, selecting an endpoint/centre instead of the curve) plus the 'point first' ordering for coincident and midpoint. The relation parameter itself is never discussed, and the point count required per relation type is left unstated.

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

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

The first sentence gives a specific verb (adds) and resource (a geometric relation) plus a scope qualifier ('sketch entities of the open sketch'), which cleanly separates it from assembly-level add_mate and from add_sketch_dimension. It does not explicitly name a sibling as the wrong choice, but the sketch-scoped phrasing makes the boundary inferable.

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 tool operates on 'the open sketch', so an agent can infer start_sketch must precede it, and the vertex note hints that coincident/midpoint may need point picking. There is no explicit guidance on when to use this versus add_sketch_dimension or when a relation is invalid for a given entity type.

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 as a non-read-only, non-destructive, non-idempotent creation operation. The description adds useful context that it consumes an open or selected sketch and creates sheet metal geometry, but it does not disclose failure conditions, whether it creates a feature in the tree, or what happens when both an open and selected sketch exist.

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 compact sentence with no wasted words, and the key action and source are front-loaded. Nothing is repeated from the schema or annotations.

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

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

For a creation tool that depends on an existing sketch and has sibling alternatives, the description is too sparse. An output schema means return values need not be explained, but prerequisites, interaction with edge_flange, and the meaning of undocumented parameters 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?

The schema describes three of four parameters well, but the description contributes no parameter semantics at all. The undocumented 'reverse_thickness' parameter is left without explanation in either the description or the schema, and the relationship between depth and open sketch profiles is not clarified further.

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 ('Creates') and resource ('sheet metal base flange / tab'), and it identifies the required source input ('open or selected sketch'). It is clear enough to distinguish from generic sketch or extrude tools, though it does not explicitly contrast with the nearby edge_flange sibling.

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 by the phrase 'from the open or selected sketch'; there is no explicit when-to-use guidance, no mention of prerequisites beyond the sketch source, and no routing to alternatives such as edge_flange or extrude.

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 non-readonly, non-destructive, non-idempotent, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: it discloses the precedence rule (distance2_mm > 0 overrides angle_deg) and what 'flip' changes, which is exactly the kind of interaction an agent needs.

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

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

Front-loaded with the core verb, then compact parameter rules with no filler. The second sentence is dense and runs several clauses together, but every clause carries information.

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

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

With annotations and an output schema present, the description covers the operation and its mode-selection logic adequately for a multi-mode feature tool. Minor gaps remain around edge/face point selection and document context, but nothing that would cause a wrong call.

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

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

Schema coverage is 50%, so the description must compensate, and it does for the key numeric parameters: angle default 45 meaning equal sides, distance2_mm switching to a two-distance mode, and flip's effect. edge_points/face_points are only deferred by reference ('as for fillet'), leaving their selection semantics dependent on the sibling's documentation.

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

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

The opening 'Bevels edges' states a specific operation on a specific entity, and the rest of the description clarifies the geometric meaning of the chamfer parameters. It does not explicitly contrast with the sibling 'fillet' (which rounds rather than bevels), so an agent must infer that distinction, but the verb+resource are unambiguous.

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

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

Usage is implied through parameter behavior ('Default: distance_mm at angle_deg', 'With distance2_mm > 0 ...'), which tells the agent which mode to pick, but there is no explicit when-to-use/when-not guidance and no mention of prerequisites such as an active part or a selected edge.

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 readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds that the operation targets the active assembly and reports volumetric collisions only, but says nothing further (e.g. whether it requires an open assembly or how many components are scanned).

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 clean sentence with zero filler and the object of the check front-loaded. Its brevity costs a little 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 rich annotations, an output schema covering results, and no parameters, the definition needs little more than stating scope. Only the prerequisite (an active assembly with multiple components) and the relationship to 'check_model' are left implicit.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter semantics to explain and the description correctly avoids inventing any.

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 ('Checks the active assembly') and narrows the check to 'volumetric interferences (collisions) between components', which tells an agent exactly what is being tested. It does not, however, distinguish itself from the sibling 'check_model', which plausibly overlaps.

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?

Scope ('active assembly') implies the context in which it applies, but there is no explicit when-to-use / when-not-to-use guidance and no pointer to 'check_model' as the alternative for broader validation. Usage must be inferred.

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

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

Annotations already establish that this is a safe, read-only, idempotent, non-destructive check. The description adds useful behavioral context by naming the specific problem classes it detects, which is meaningful beyond the annotations, though it does not describe outcomes on failure.

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

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

A single front-loaded sentence with no filler. Every clause adds diagnostic scope information.

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

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

With no parameters and an output schema present, the description needn't explain return values. It adequately covers what the tool inspects, though it leaves some ambiguity about the relationship with check_interference and what the agent should do based on failures.

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 no parameter semantics to explain; baseline is 4. The schema is empty and fully covered, and the description does not need to compensate for any undocumented inputs.

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 ('checks'), resource ('the active part'), and enumerates the exact fault classes inspected: rebuild errors, multiple bodies, and geometry faults. It is clear what the tool does, but it does not differentiate itself from the sibling check_interference, which could overlap in the mind of an agent.

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 as a diagnostic/validation step on the active part, but the description gives no explicit when-to-use conditions, prerequisites, or comparison to check_interference. There are no exclusions or alternative-tool routing instructions.

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 non-read-only, non-destructive, non-idempotent, so the agent knows this mutates the model and repeat calls may stack. The description adds geometric semantics (axis through origin vs edge-based axis) but says nothing about what gets created in the feature tree, whether the original feature is consumed, or what happens on failure — meaningful gaps for a mutation tool.

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

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

Front-loaded with the core operation, then the axis explanation as a secondary paragraph. No filler, though the line-broken formatting is a little awkward and the `reverse` omission means the size isn't the issue — content is.

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

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

Output schema exists, so return values needn't be described, and annotations cover the safety profile. The description handles the trickiest parameter (edge-axis definition) well; the remaining gap is the undocumented `reverse` flag and no statement of where the resulting feature lands.

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

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

Schema coverage is only 33%, and the description carries real weight for `axis` and `axis_edge_point`, which are barely documented in the schema — that is genuine added value. But `reverse` is never mentioned in either place, and `angle_deg` semantics are only implied by 'spread evenly over angle_deg'. The partial coverage and the undocumented flag pull this to a 3.

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: 'Repeats features ... around an axis', with the meaning of count (total copies, original included) and the angular spread spelled out. It is functionally distinguishable from siblings like linear_pattern or mirror, though it never names them explicitly.

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

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

Useful implied guidance: features come from get_feature_tree, so the agent knows it must look up feature names first. However, there is no explicit when-to-use vs linear_pattern/mirror, and no stated precondition such as which document or body the pattern applies to.

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 a mutating, non-idempotent, non-destructive operation; the description adds genuinely new behavior by stating that 'the new sketch entities follow the model when it changes' — associative/reference geometry semantics the agent could not infer from annotations. It stops short of saying what happens if no sketch is open or if both point lists are null.

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 the verb and target first, then the selection semantics. Slightly dense nesting ('all the edges of each face with a point in face_points') but no wasted sentences.

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

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

An output schema exists so return values need not be described, and both optional parameters are explained including units and coordinate frame. The remaining gap is the implicit prerequisite of an active sketch and the all-null case, minor for a two-parameter tool.

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

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

With 0% schema description coverage, the description carries the full burden and largely succeeds: face_points selects faces by containing a point, edge_points selects edges by containing a point, and the coordinates are specified as [x, y, z] in millimetres in model coordinates. It does not clarify the null default or whether both lists may be 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?

States a specific verb and resource ('Projects edges of the model into the open sketch') and names the CAD operation it maps to ('Convert Entities'), which is far more informative than the bare name. It is distinguishable from siblings such as sketch_offset or sketch_line, though it does not explicitly contrast itself with them.

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

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

The phrase 'into the open sketch' implies the prerequisite that a sketch must already be active (via start_sketch), but this is never stated as a rule or failure condition. There is no guidance on when to prefer this over sketch_offset or manual sketch_line drawing.

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 as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context: it depends on an open sketch, ignores z when converting to model coordinates, and returns both sketch coordinates and distance from the sketch plane. It does not describe error behavior if no sketch is open.

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 two dense sentences with no wasted text. It front-loads the purpose and immediately clarifies the two directional cases, which are the key details an agent 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?

Given the output schema and rich annotations, the description provides everything needed: what is converted, which coordinate system each direction expects, how z is treated, and what is returned. No critical behavioral or parameter information is missing.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, and it does: to="sketch" expects a model (x, y, z) point, while to="model" expects a sketch (x, y) point and ignores z. This fully maps to the four parameters and their directional semantics.

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: converting a point between model coordinates and open-sketch coordinates. It also explains the two conversion directions, so the agent can distinguish this from siblings like convert_entities or measure.

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

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

The description implies when each direction applies by explaining to="sketch" and to="model" semantics, but it does not explicitly say when to choose this tool over alternatives or note any prerequisites beyond the mention of an 'open sketch'. Usage is implied rather than framed as 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 it is non-read-only, non-idempotent and non-destructive; the description adds value beyond that by explaining offset direction, that flip=True mirrors to the other side, and that the tool returns a name to feed into select_plane. It does not cover failure behavior for an invalid reference or a non-planar face_point, which keeps it off a 5.

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

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

Four tight sentences: purpose and offset first, reference modes second, flip third, return value last. The loft-profile example is the only optional flourish and it usefully signals the intended workflow.

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

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

For a 4-parameter mutation with an output schema already documenting return values, the description covers the geometry semantics, both reference modes, the flip behavior and the handoff to select_plane. Nothing an agent needs in order to invoke it correctly is missing.

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

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

Schema coverage is only 25% (only offset_mm is annotated), so the description has to carry the rest — and it does, giving concrete reference values, the [x, y, z] mm format for face_point and its planar-face requirement, and the meaning of flip=True. It omits that offset_mm must be strictly positive (exclusiveMinimum: 0), which is the only substantive gap.

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

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

States a specific verb and resource plus the defining constraint: a reference plane parallel to another, offset_mm away. It also names the downstream consumer (select_plane), which distinguishes it from sibling selection/creation tools without opening any schema.

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

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

Explains the two mutually exclusive reference modes — a named/base plane ("front", "top", "right" or a plane name) versus a face_point on a planar face — and where the result is used. It stops short of stating when not to use it (e.g. versus select_plane on an existing plane), so it is clear context but not full routing guidance.

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

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

The description discloses non-obvious behavior beyond the annotations: through_all ignores depth_mm, reverse flips direction, flip_side removes material outside the profile, up_to_point cuts to a face, depth2_mm cuts in the opposite direction, and draft_angle_deg tapers walls. These details are critical for calling the mutation correctly.

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

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

The description is front-loaded with the core operation and then packs parameter behavior into short, useful clauses. Every sentence adds operational information, 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 complex CAD mutation tool, the description covers the operation and all parameter interactions, and the output schema handles return values. It is almost complete, though it could more explicitly state prerequisites such as having an active or last sketch and clarify relationships to extrude/hole siblings.

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

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

Schema description coverage is only 38%, but the description compensates by explaining the meaning and interaction of all eight parameters, including through_all, depth_mm, reverse, flip_side, up_to_point, depth2_mm, draft_angle_deg, and draft_outward. It adds substantial meaning beyond the sparse schema descriptions.

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 operation: an extruded cut (holes, pockets) using the last sketch. This clearly separates it from additive extrusion by naming it a cut, but it does not explicitly distinguish it from the sibling hole or extrude tools.

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

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

Usage is implied by 'holes, pockets' and 'with the last sketch', but there is no explicit guidance on when to use this instead of extrude, hole, or other cut-related siblings. No exclusions or prerequisites beyond the last-sketch reference 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 destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond the annotations — it does not say whether the deletion is irreversible, what happens to dimensions or geometry driven by that equation, or whether dependent features break. For a destructive operation on a parametric model this is thin.

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 the destructive verb first and the cross-reference tucked in a parenthetical. Nothing is wasted 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?

An output schema exists so return values need not be explained, and the annotations cover the safety profile. What is left unsaid — consequences for dependent equations and the validity range of the index — is exactly what an agent needs before firing a destructive call, so the definition is adequate but not 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 0% and the single 'index' parameter is bare, so the description carries the burden. It does tell the agent where the index comes from ('see get_equations'), which is real added meaning, but it never says whether the index is zero- or one-based or what happens if it is out of range.

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 plus identifier: 'Deletes the equation with that index'. The parenthetical '(see get_equations)' scopes it against add_equation and the broader delete_feature sibling. It stops short of an explicit 'not delete_feature' statement, so a 4 rather than 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 pointer to get_equations implies the precondition (obtain an index first), but usage is only implied. There is no explicit statement of when to use this versus deleting a feature, and no warning about when not to call 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 destructiveHint=true, idempotentHint=false, so the safety profile is known. The description adds nothing beyond that: it doesn't say whether dependent/child features are also removed, whether the operation is irreversible, or what happens if the name doesn't exist.

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 the destructive action front-loaded and the discovery hint attached inline. No filler; only slightly thin 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?

Return values are covered by the output schema, so the description needn't explain them. For a destructive mutation, however, the cascade behavior and failure mode are important missing context.

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

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

Schema description coverage is 0%, so compensation was needed. The description does clarify that 'name' means a feature-tree entry and points at get_feature_tree for discovery, but gives no matching rules (case sensitivity, exact vs partial name).

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

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

States a specific verb and resource ('Deletes a feature') plus the identifying key ('by name'), which is more informative than the bare tool name. It doesn't explicitly contrast with the sibling suppress_feature, 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 parenthetical '(see get_feature_tree)' gives a concrete prerequisite for obtaining a valid name, which is implied usage guidance. There is no statement about when to prefer suppress_feature over deletion, or any preconditions such as the feature being present.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and closed-world scope, so the mutation profile is covered. The description adds the useful targeting context (acts on the selected edge or an indicated point), but says nothing about failure modes when no valid edge exists or whether it adds a feature to the feature tree that can be edited later.

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 verb, resource, and target in order and no filler. It is efficient, though its brevity borders on under-specification rather than true crispness.

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

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

An output schema exists, so return values need not be explained, and 3 of 4 parameters are documented in-schema. Missing pieces are prerequisites/error behavior and any relationship to base_flange, which matter for a non-idempotent feature-creation tool.

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

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

Schema coverage is 75%, so baseline is 3. The description hints that edge_point_mm is the 'indicated edge' mechanism, which is the one parameter the schema leaves undocumented, but it gives no format or coordinate-frame detail to compensate for that gap.

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

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

States a specific verb and resource: 'Creates a sheet metal edge flange', plus the target ('selected or indicated edge'). An agent can tell this apart from base_flange by the word 'edge', but the description never names base_flange explicitly, so sibling 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?

The phrase 'selected or indicated edge' implies the prerequisite (an edge must already be selected, or supplied via edge_point_mm), but usage is only implied. There is no statement of when to choose this over base_flange, or what to do if no edge is selected.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the description's main contribution is clarifying the non-feature-creating outcome, which is genuinely useful. It does not disclose what happens to the sketch geometry after closing, nor the behavior on a repeat call despite idempotentHint=false.

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

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

A single short sentence with zero filler, front-loaded on the action and followed by the key qualifier. 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 parameters and an output schema present, the description need not explain return values, and the core effect is covered. A note on the state requirement (a sketch must be open) and on post-close geometry would make it complete.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline for a parameterless tool applies. The description does not add misleading or missing argument details.

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 ('Closes the open sketch') and adds a scope detail ('without creating a feature') that distinguishes it from feature-creating exits like extrude or revolve. It never names its natural counterpart start_sketch, so the sibling pairing is only 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?

The phrase 'without creating a feature' hints at when to pick this over terminating a sketch via a feature operation, but that condition is left for the agent to infer. There is no explicit statement of when to call it, ordering relative to start_sketch, or what happens if no sketch is open.

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

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

The annotations flag destructiveHint=true and idempotentHint=true, and the description supplies the missing context that explains those hints: "Existing files with the same name are replaced." It also covers directory-creation behavior ("Created if missing") and the key safety fact that the open document is untouched, which the agent cannot get from annotations alone.

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

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

The purpose and the file-replacement warning are front-loaded, and per-parameter notes are line-separated so they scan well. There is slight redundancy between the "e.g. [\"step\", \"stl\"]" example and the "Supported:" list that follows it, but the overall length is justified by the information 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 only two optional parameters, no enums, and an output schema already present, the description must cover the format vocabulary, default resolution, path rules, and side effects; it does all four. An agent has everything it needs to invoke the tool correctly without additional context.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does: formats gets an explicit supported-value list and a default-config fallback, and directory's absolute/relative resolution, "{format}" substitution token, and auto-creation are all spelled out. This is far more than the schema 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?

"Exports the active document to exchange formats" gives a specific verb and resource, and the format list (step, stl, pdf, ...) makes the scope concrete. It does not explicitly distinguish itself from the sibling save_document or export_flat_pattern, so sibling differentiation is left to inference.

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

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

The description gives conditional guidance for each parameter (omit formats to use the user's configured formats, omit directory to use the configured directory), which is useful but is parameter behavior rather than when-to-use-this-tool guidance. It never names an alternative such as save_document or export_flat_pattern, so the choice between export paths is only implied by "exchange formats".

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 destructive=true and idempotent=true, but the description adds critical overwrite context: existing files with the same name are replaced. It does not explain the effect of remove_bends or failure modes, but it adds meaningful destructive behavior beyond annotations.

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

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

Four short sentences, front-loaded with the action and overwrite warning, followed by useful path semantics. No filler or redundant restatement.

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

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

An output schema exists and annotations cover the safety profile, so return values and destructive status need not be explained. The description still leaves remove_bends and error/precondition behavior undocumented.

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

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

Schema description coverage is 0%, so the description must compensate. It fully explains path as absolute/relative or omitted to export next to the part, but never explains what the remove_bends boolean does, leaving a clear gap.

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

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

States a specific verb and resource: exporting the flat pattern of the active sheet metal part to a DXF file. The sheet-metal/DXF specificity distinguishes it from the generic export_document sibling even without naming it.

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

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

Implies usage for exporting a sheet metal flat pattern and explains the path-omission behavior. It does not state when to use export_document instead or mention prerequisites/exclusions such as requiring an active sheet metal part.

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?

Beyond the annotations, the description discloses important behavioral details: it creates a solid, auto-closes open sketches, allows open profiles only for thin-wall extrusions, and can leave the result as a separate body when merge=False. It also clarifies direction and draft behavior.

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

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

The first sentence gives the core action and resource, and the following lines efficiently map parameter names to behavior. The structure is dense but appropriate for a nine-parameter CAD operation, with no wasted prose.

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

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

For a complex extrusion tool with nine optional parameters, the description covers most decision-relevant behavior, including end conditions, thin walls, merge behavior, and draft. It is nearly complete, though reverse and the exact effect of some combinations remain lightly 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 description coverage is 44%, so the description must compensate, and it largely does by explaining end_condition modes, depth2_mm interaction with midplane, draft direction, thin-wall behavior, and merge=False. It leaves reverse unexplained, which prevents a perfect score.

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 CAD operation: extruding the last sketch into a solid. It clearly distinguishes this from cutting sibling operations like cut_extrude by specifying that the result is a solid, and it notes automatic sketch closing.

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

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

The description implies usage after creating a sketch and explains several conditional behaviors, such as open profiles being allowed only with thin_wall_mm. However, it does not explicitly name alternatives like cut_extrude or sweep and does not state when not to use this tool.

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

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

Annotations mark it as a non-readonly, non-idempotent mutation, and the description adds a genuinely non-obvious side effect: tangency propagation ('Edges tangent to the chosen ones are rounded too'), which is exactly the kind of detail annotations cannot carry. It still omits failure modes (radius too large for the edge) and whether partial success is possible.

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 compact sentences, front-loaded with the operation, then per-parameter semantics, then the propagation caveat. No filler and no restatement of the tool name.

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

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

With one documented parameter, two undocumented point arrays, and an output schema present, the description covers the essentials an agent needs to call it. Only the mutual-exclusivity/at-least-one requirement for the point arrays is missing, which is a small but real hole for a 3-parameter tool.

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

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

Schema coverage is only 33% (radius only), so the description must compensate, and it does: it defines edge_points and face_points semantics plus units and coordinate frame ([x, y, z] in mm, model coordinates). The remaining gap is that it never states that at least one of edge_points/face_points must be supplied, leaving the required combination ambiguous.

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

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

States a specific verb and resource ('Rounds edges') plus the defining constraint ('constant radius'), which cleanly separates it from the point-selection siblings (select_edge_at_point) and adjacent features. It does not explicitly contrast with chamfer or sketch_fillet, so an agent must infer the distinction, but the geometric intent is unmistakable.

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

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

Usage is only implied: the two alternative targeting modes (edge_points vs face_points) are described, which hints at when to use which, but the description never says when to call fillet rather than chamfer, skirt, or sketch_fillet, nor what prerequisites exist. Minimum-viable routing guidance.

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

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

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world behavior. The description adds real context beyond that: the sketch is mutated by accumulating relations and dimensions drawn from the sketch origin, so the agent knows the geometry becomes dimension-driven. It is silent on failure modes (already fully defined, under-constrained leftovers), how many constraints get added, and whether calling twice duplicates anything — notable given idempotentHint=false.

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 well-formed sentence that front-loads the action and its effect. The trailing parenthetical naming get_dimensions / set_dimension is slightly awkward inline rather than as a separate clause, 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?

No parameters and an output schema exists, so the definition needn't cover return values; given that, the sketch-mutation intent and the dimensions-from-origin behavior are the key facts and both are present. The remaining gap is resilience behavior — what the agent should do before calling (is a sketch open?) and whether re-running is safe.

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

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

The tool takes zero parameters and the description correctly describes no argument behavior, implicitly relying on ambient state (the open sketch). Baseline 4 applies; nothing is missing because there is no schema surface to explain.

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 — adds the relations and dimensions needed to make the open sketch fully defined — including the precondition that a sketch must be open. It is clear what the tool does, but it never contrasts itself with the closely related per-entity siblings add_sketch_dimension and add_sketch_relation, which an agent could easily pick by mistake.

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 ('that the open sketch needs to be fully defined') and a downstream editing path is named (get_dimensions / set_dimension), which is useful. However, there is no explicit statement of when to prefer this over add_sketch_dimension/add_sketch_relation, nor what happens if the sketch is already fully defined, so the agent must infer selection and 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?

The annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower, and the description still adds a genuinely important behavioral fact beyond them: it will launch SolidWorks if it is not running, a non-trivial side effect an agent should anticipate. It does not say what happens when SolidWorks is running but no document is open (error versus empty result), which is the main remaining ambiguity.

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

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

Two short sentences with zero filler; the primary content (what is returned) is front-loaded and the side-effect caveat follows. Nothing repeats the name or title.

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

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

An output schema exists, so return values need not be spelled out, and the annotations cover safety; the description supplies the one piece of context structured data cannot express (auto-start behavior). The only gap is undefined behavior when no document is active, which matters for an agent deciding whether to call it defensively.

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

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

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. No parameter text is needed and none is missing.

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

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

The description names the exact resource returned — the active document's name, path, type, plus the SolidWorks version — so the agent knows precisely what data it yields, and it is clearly distinguishable from data-querying siblings like get_feature_tree or get_mass_properties. It is a noun-phrase specification of return values rather than an explicit verb, which slightly weakens the action framing.

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: an agent can infer this is the way to learn which document is currently open before doing document-related work. There is no explicit when-to-use, no mention of alternatives (e.g. versus a listing tool), and no stated 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 readOnly, idempotent, non-destructive, so safety is fully covered. The description's real contribution is scope ('solid bodies of the active part') and units (mm), which is useful, but it does not say what happens with no active part, no solid bodies, or surface-only bodies.

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

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

One tight sentence with the returned quantities and units front-loaded; every clause carries information and nothing is repeated from annotations or schema.

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

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

An output schema exists, so return structure need not be restated, and the description still names the returned values and units. Scope is well bounded (active part, solid bodies only); only edge-case behavior for empty/no-active-part states is missing.

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

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

Zero parameters, so there is no parameter semantics to explain – baseline 4 applies. The description correctly implies the call is fully parameterless and scoped implicitly to the active document.

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: bounding box of the solid bodies of the active part, with exact outputs (min/max X/Y/Z and overall size in mm). It is clearly distinguishable from get_mass_properties and get_dimensions by content, 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?

Usage is only implied by the phrase 'of the solid bodies of the active part' – an agent can infer it queries current geometry extents, but no when-to-use vs. measure/get_dimensions guidance or prerequisites (e.g., an active part must have solid bodies) are 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, and an output schema exists. The description adds useful context that it targets the 'active document' and gives example properties, but does not describe return format or behavior beyond the structured fields.

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 compact sentence, front-loaded with the resource and scope. The trailing 'as used in BOMs and title blocks' clause earns its place as domain context, though the phrasing could be slightly tighter.

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 zero params, full annotations, and an output schema, the description needs to convey only purpose and scope, which it does. The only minor gap is not distinguishing this read from the set_custom_property write sibling.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. Schema coverage is 100% and nothing is left ambiguous.

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

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

States a specific resource (custom properties) scoped to the active document and gives concrete examples (description, part number). However, it is phrased as a noun rather than a verb+resource and never mentions the sibling set_custom_property, leaving the read-vs-write distinction 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?

'as used in BOMs and title blocks' describes what the properties are for, not when to call this tool or how it differs from get_active_document_info or set_custom_property. No when/when-not guidance or alternative routing is 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 readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds real value on top: units (mm or degrees) and the exact dimension-name convention returned, which is what an agent needs to chain into set_dimension. No rate/limit or ordering details, hence not a 5.

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

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

A single dense sentence with no filler; the parenthetical efficiently encodes the default-parameter rule. Slight awkwardness in embedding the clause mid-sentence rather than front-loading it, 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?

Output schema exists, so return-shape explanation is unnecessary, and the description still previews the meaningful content (names + unit-bearing values). For a one-param read tool this is close to complete; only the accepted input format for a non-empty 'feature' is left implicit.

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

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

Schema coverage is 0% and the single parameter has no description, so the description must carry the burden — and it does: 'of the whole part when feature is empty' fully explains the default ''. It doesn't clarify what string format a non-empty feature value should take (feature name vs. sketch name), which is the remaining gap.

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

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

States a specific verb+resource: reads dimensions of a feature, sketch, or the whole part, and specifies the naming format (D1@Boss-Extrude1) and units. It distinguishes scope via the 'feature is empty' clause and pairs itself with set_dimension, though it doesn't contrast against near-neighbors like measure or add_sketch_dimension.

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 set_dimension' establishes the primary workflow (read dimensions to then modify them), and the parenthetical defines the empty-feature case explicitly. It stops short of exclusions — nothing says when to prefer measure or get_feature_tree instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds useful scoping context that the action applies to the active document and that results are indexed, but nothing about ordering, empty states, or what 'index' means behaviorally.

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 compact sentence with no filler. It is front-loaded with the core resource, though the fragmentary phrasing makes it slightly less crisp than a full verb-led 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?

Output schema exists, so return values need no explanation here, and the zero-parameter read operation is simple. Mentioning the active-document scope and the index field is sufficient context for correct invocation.

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

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

The tool takes zero parameters, so the baseline is 4; the schema is empty and the description correctly adds nothing spurious. There are no parameter semantics to clarify.

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 (global variables and equations) scoped to the active document, which distinguishes it from write-oriented siblings like add_equation, delete_equation, and set_dimension. It reads as a noun phrase rather than a verb+object, but the retrieval intent is unambiguous.

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

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

There is no explicit statement of when to call this versus alternatives such as get_dimensions, get_custom_properties, or add_equation/delete_equation. The read-only nature is implied but no conditions or exclusions are 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that feature types are returned, but does not disclose ordering, tree nesting, whether suppressed features are included, or behavior when no document is active.

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 compact sentence with no filler. The core resource and the returned feature-type detail are both front-loaded.

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

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

Given a zero-parameter read-only tool with a full output schema and annotations, the description is largely complete. Remaining gaps are minor behavioral details such as tree ordering and handling of suppressed features.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics to clarify beyond the already-complete empty schema.

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

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

The description states a clear resource—features of the active document's design tree—and adds that each item includes its type. It is more specific than the tool name alone, though it does not explicitly differentiate itself from nearby inspection tools such as get_active_document_info or get_dimensions.

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

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

It implies the tool inspects the active document's feature tree, but gives no explicit when-to-use guidance, prerequisites, or alternatives. An agent must infer that this is for listing features rather than querying dimensions, properties, or document metadata.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the meaningful scoping detail that it reads the *active* document and handles both parts and assemblies, but says nothing about cost, caching, or failure modes. Given annotation coverage, this is an appropriate 3.

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 fragment that front-loads the returned quantities with zero filler. Every word carries information and nothing is repeated from the title or annotations.

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

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

With an output schema present, the description need not enumerate return fields, and with zero parameters there is no input to document. The only shortfall is the unaddressed interaction with 'measure' and the lack of a stated precondition for the active document.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no input is required by framing everything around the already-active document.

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

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

The description names the specific quantities returned (mass, volume, surface area, centre of mass) and the scope (active document, part or assembly), so an agent knows exactly what the tool yields. It is a noun phrase with no explicit verb and does not differentiate itself from the nearby sibling 'measure', which is a plausible overlap an agent must resolve on its own.

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

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

There is no statement of when to use this versus alternatives, and the sibling list contains 'measure', 'get_bounding_box', and 'get_dimensions', which an agent could reasonably confuse with this. The 'active document' qualifier implies a precondition but never says it explicitly (e.g. what happens if no document is active).

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

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

The description adds useful behavior beyond the annotations: it changes view orientation unless view='current', zooms to fit, and does not modify the model. This clarifies the side-effect profile while remaining consistent with readOnlyHint=false and destructiveHint=false.

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 are front-loaded with the tool’s output and purpose, followed immediately by the important side effects. Every sentence earns its place.

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 one-parameter screenshot tool with annotations and no output schema, the description is nearly complete: it states the return type, visual-check purpose, view behavior, zoom behavior, and that the model is not modified. Only minor parameter enum details are left implicit.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the special behavior of view='current' and implies orientation changes for other views, but it does not explain the other enum values or the default isometric view.

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 clear verb/resource: producing a PNG image of the active model for visual verification. It distinguishes the tool’s output from sibling model-inspection tools like get_mass_properties or check_model, though it does not explicitly name 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?

The phrase 'to check the result visually' implies when to use the tool, but the description does not give explicit when-not-to-use guidance or name alternative inspection tools such as check_model or zoom_to_fit.

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 the generic non-readonly/non-destructive profile; the description adds real behavior beyond that — no thread is modelled for tapped holes, metric sizes carry standard ISO 4762/ISO 10642 head dimensions, and the face is derived from the first center point. It stops short of saying what happens on failure (centers off-face) or the cut direction/start.

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

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

Front-loaded purpose sentence, then per-parameter lines in the order an agent would reason about them (centers, size/fit, depth, style). Slightly compressed prose in the last clause, but no sentence 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?

For an 11-parameter feature-creation tool with an output schema present, the description covers the decision-relevant inputs (size vs diameter, through vs depth, style variants) well. Minor gaps remain on the counterbore/countersink dimension parameters and error conditions, but nothing critical to a correct call is missing.

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

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

Schema coverage is 55% across 11 parameters, so description carries real burden and does: centers format and coordinate system, size as metric designation, fit semantics (ISO 273 clearance vs tapped drill diameter), depth_mm or through_all=True, and style with standard counterbore/countersink dimensions. The explicit counterbore_/countersink_diameter_mm and angle parameters are only gestured at via 'otherwise give them'.

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 plus the geometric constraint: 'Drills round holes into a planar face, perpendicular to it.' An agent knows exactly what geometry results. It does not, however, distinguish itself from siblings like cut_extrude or sketch_circle+cut, so a 4 rather than 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?

Usage is implied rather than stated: the note that all centers must lie on the SAME face, found via the first center, tells the agent when the tool is applicable. There is no explicit 'use this instead of cut_extrude' guidance or stated prerequisites such as an existing part/document.

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

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

Annotations already declare readOnly=false, idempotent=false, and destructive=false, so the safety profile is covered. The description adds that placement is in millimeters and that the insertion targets the active document, but says nothing about whether a new instance/reference is created, what happens on repeat calls, or what the operation requires of the source part.

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 that front-loads the action, the object, the target document, and the units. 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?

An output schema exists, so return values need not be described, and annotations cover safety. The remaining gap is the required 'path' argument's format/source and any prerequisite check on an active assembly, which the description does not supply.

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

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

Schema description coverage is 0% – the schema exposes only titles. The description clarifies the x/y/z units (mm) but never explains the required 'path' parameter (presumably a file path to the part/sub-assembly) or the 0 defaults. With zero schema coverage, the single most important parameter is left 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 and resource ('Inserts a part or sub-assembly component') plus the target container ('active assembly'). This distinguishes it from siblings like new_part and new_assembly, though it does not name any sibling explicitly.

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

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

'Active assembly' implies the prerequisite that an assembly document must already be open, which is useful implied guidance. However, there is no explicit when-to-use vs. when-not, and nothing tells the agent how this differs from new_assembly or new_part in a workflow.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuine scope information — the insert fans out across ALL views in the active drawing, not a selected view — but says nothing about what happens on repeat invocation, which matters given idempotentHint=false (duplicate dimensions are likely).

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-loaded with the action and immediately followed by its scope of effect. Nothing to cut.

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

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

With an output schema present, return values need not be explained, and with no parameters the call signature is trivial. The remaining gap is precondition/failure context — what happens if no drawing is active or no dimensions are marked, and whether re-running duplicates dimensions.

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

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

The tool takes zero parameters, so the baseline is 4. The description adds no parameter semantics, but none are needed; the only implicit input is the active document and the marked-dimension state in the model.

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

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

The description names a specific verb and resource ("Inserts model dimensions") and scopes it precisely ("marked for drawing across all views in the active 2D drawing"). It is distinguishable from the dimension siblings (get_dimensions, set_dimension, add_sketch_dimension) by its drawing-view import semantics, though it never names an alternative 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 implied rather than stated: the agent must infer that a 2D drawing must be active and that dimensions must already be marked in the model before calling. There is no explicit when-not-to-use guidance and no routing to sibling tools such as get_dimensions or add_sketch_dimension.

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 establish that this is a non-readonly, non-destructive, non-idempotent operation. The description adds important behavioral semantics beyond that: count includes the original, reverse controls the negative direction, and the second direction produces a grid rather than a single row.

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

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

Two tightly written sentences, front-loaded with the core action and extended only to explain the optional grid direction. There is no wasted wording.

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

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

An output schema exists, so the description need not document return values, and the annotations cover the safety profile. The description is complete for the main pattern operation, with only minor gaps around reverse2 and the exact meaning of direction2's empty default.

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 44%, so the description must carry weight. It compensates well by explaining features as names from get_feature_tree, count as total including the original, spacing_mm, reverse direction, and the second-direction grid parameters; only reverse2 and some default behavior remain unexplained.

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

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

The description states a specific verb and resource: it repeats selected features in a linear row along a model axis, including grid behavior via a second direction. This clearly distinguishes it from circular patterning by geometry, though it does not explicitly name a sibling alternative.

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 useful setup context, notably that feature names come from get_feature_tree and that direction2/count2/spacing2_mm create a grid. However, it does not state when to use this tool instead of circular_pattern or mirror, nor does it give exclusions or prerequisites for patterning.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them by scoping results to the active document and noting that the active configuration is marked in the output, which affects how the agent interprets 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 front-loaded sentence with no filler; the scope constraint and the active-configuration flag both land immediately.

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

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

With an output schema present, return values need no prose, annotations cover safety, and there are no parameters, so the description is nearly complete. The only residual gap is that it is silent on whether parent/sub-configurations are included or how an empty-configuration list behaves.

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?

Zero parameters, so there is nothing to disambiguate and the schema requires no explanation. The description correctly spends no words on parameters and instead directs attention to the document scope.

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 ('Lists') plus resource ('all configurations') and an explicit scope ('active part or assembly document'), with the added detail that the active one is flagged. It is naturally distinguishable from add_configuration and activate_configuration, though it never names a sibling to compare against.

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: an agent can infer 'call this to discover what configurations exist before activating one,' but the description states no when-to-use condition, no prerequisites, and no alternative tools. Nothing misleading, just unstated.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description adds the non-obvious matching semantics - that 'search' matches a substring of either the name or the category. It does not state what an empty search returns (presumably the full catalog), which is the one behavioral detail an agent would want.

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

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

Two sentences, zero filler. The capability and its filter semantics come first, and the downstream usage instruction comes last, which is the correct front-loading order for a lookup 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?

An output schema exists, so return values need not be explained, and for a single optional-string read tool the description covers what the agent needs to call it correctly. The only gap is the default/empty-search behavior, which matters because the parameter is not 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 description coverage is 0%, so the description must carry the parameter, and it does: 'search' filters on part of the name or category, with concrete examples ('6061', 'steel', 'abs'). It omits that the parameter defaults to empty and what that means, and does not mention case sensitivity.

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 (materials in the SolidWorks material databases) and the scoping operation (filtered by 'search'), which an agent can distinguish from the mutating sibling set_material. It is specific enough to act on, though it never uses a list/retrieve verb of its own, relying on the tool name for that.

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

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

It gives clear routing in one clause: 'Use the exact name with set_material', which tells the agent this is the discovery step preceding set_material and that the returned name must be reused verbatim. There is no explicit statement of when not to use it (e.g. when the material name is already known), 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 cover safety (readOnly=false, destructive=false, openWorld=false), and the description adds substantive behavioral detail beyond them: the cut=True flag reverses material addition into removal, profiles must be closed, and guide curves must touch every profile. It leaves failure behavior and feature-creation effects unstated, 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?

Three dense sentences with the core operation first, then the optional parameter, then the boolean modifier and prerequisites. Every clause carries information an agent would otherwise have to guess; nothing is restated from the schema or annotations.

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

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

An output schema exists, so return values need no explanation, and all three parameters plus the sketch-closing prerequisite are covered. What remains thin is error/validity behavior (what happens if profiles are not coplanar-compatible or guides miss a profile) and the format of the sketch arguments.

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

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

With 0% schema description coverage, the description carries the load and does it well: cut is explained by effect, guide_sketches by its geometric constraint ("touching every profile"), and profile_sketches by cardinality and ordering ("two or more ... in order"). It does not say what format the sketch identifiers take, which keeps it off a 5.

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

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

"Loft through two or more closed profiles drawn on different planes" gives a specific verb (loft) and the exact geometric resource, and the parenthetical reference to create_plane clarifies the plane requirement. It does not, however, distinguish itself from the closest sibling sweep, which an agent would plausibly weigh against it.

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 supplies real prerequisites ("Close the sketches first (end_sketch)", "see create_plane") that imply when the tool can be called. But it never says when to prefer loft over sweep/extrude/revolve, nor when a loft is inappropriate, so 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds two behaviors the annotations cannot express: the call 'replaces the current selection' (a UI side effect) and coordinates are in mm/model space, which matters for agent-side coordinate construction. It does not cover error behavior for points that miss geometry, but with annotations carrying the safety profile this is solid.

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

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

Two tightly packed sentences, front-loaded with the primary capability, followed by the side-effect warning. No filler or restatement of the tool name.

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

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

An output schema exists, so return values needn't be explained, and the coordinate convention is covered. Gaps remain for a 4-parameter tool: the type1/type2 discriminators and the requirement that point2 be provided to get distance/angle are left to inference rather than stated.

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 0%, so the description carries the burden and does explain point1/point2 as [x, y, z] in mm model coordinates lying on the target geometry. However, type1/type2 (enum face/edge/vertex, defaulting to face) are never mentioned, so a quarter of the parameters — and the ones that determine what 'point lying on' means — are undocumented in both schema and description.

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

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

States a specific verb (measures) plus the two modes it supports: a single entity (area, length, diameter) or distance/angle between two points selected on geometry. An agent can tell what it does without opening the schema. No sibling is named, but no other tool in the list measures geometry, so the risk of confusion is low.

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 two modes are described, which implies when each applies (one point = single entity, two points = distance/angle), but there is no explicit when-to-use/when-not guidance and no comparison to related siblings such as get_bounding_box, get_dimensions, or get_mass_properties that could also answer measurement-ish questions.

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 indicate this is a non-read-only, non-idempotent, non-destructive operation. The description adds no behavior beyond the basic purpose: it does not say whether the original features remain, whether new features are created, or what happens to dependent 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?

The definition is a single front-loaded sentence with no wasted text. It packs the operation, source of feature names, plane options, and face-point format 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still, for a feature-creating mutation tool, the description is thin on behavioral consequences and usage context relative to sibling pattern/feature tools.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does this well for all three inputs: features are names from get_feature_tree, plane accepts front/top/right or a named plane, and face_point is an [x, y, z] point in mm.

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: "Mirrors features ... about a plane." It is clearly distinguishable from generic pattern tools, though it does not explicitly contrast itself with linear_pattern or circular_pattern.

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

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

It implies the tool's use for mirroring existing features and helpfully points to get_feature_tree for source names. However, it gives no explicit when-to-use guidance versus pattern tools and does not state prerequisites such as selecting a plane or face 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 already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds that the result is an empty assembly (no components) built from a template, but says nothing about where the document is created, whether it becomes the active document, or how failures (missing template) behave.

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 verb and resource, no filler. It is appropriately sized, though it leaves room for a short clause on preconditions at no real cost.

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

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

An output schema exists, so return values need not be explained. However, for a document-creation tool with zero-required, zero-documented parameters, the description omits the created document's name/location and whether it is left open as the active document - gaps an agent would care about.

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

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

Schema description coverage is 0%, so the schema alone leaves template_path opaque. The phrase 'default or given assembly template' does clarify that an omitted template falls back to the default, which is real added meaning for the single parameter, though it gives no hint about path format or overriding behavior.

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 ('Creates') and resource ('new empty assembly in SolidWorks'), which separates it from new_part and new_drawing in the sibling list. It does not explicitly name those siblings, but the resource noun is distinctive enough that an agent can route correctly.

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 no when-to-use guidance, no prerequisites (e.g. must be invoked before insert_component/add_mate), and does not contrast with new_part or new_drawing. Usage is only implied by the word 'new'.

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, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds the non-obvious behavior that three standard views and an isometric view are auto-generated, but it stays silent on side effects such as whether the new drawing becomes the active document, whether it is persisted, or what happens if no document is open.

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 creation action front-loaded and the generated-view detail immediately after. Nothing is padded or redundant.

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

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

An output schema exists, so return values need not be described, and the view set is well covered. Still missing for a document-creating tool are the template_path semantics and any statement about state changes or failure when no active document exists.

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

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

Schema description coverage is 0% and the single optional parameter template_path (default empty string) is never mentioned in the description. An agent cannot tell from either source what the empty default means (fallback default template?) or what format a path should take, so the description fails to compensate for the coverage gap.

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

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

Specific verb plus resource: "Creates a new 2D drawing from the currently active part or assembly document," and it goes further to state exactly what the output contains (Front/Top/Right 3rd-angle projections plus an Isometric view). The resource is clearly distinguishable from new_part and new_assembly, 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?

"From the currently active part or assembly document" implies the prerequisite that an active document must exist, and that other document sources are not accepted. However, there is no explicit when-to-use/when-not guidance and no pointer to related tools such as save_document or export_document for the resulting drawing.

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 it is a non-read-only, non-destructive, non-idempotent operation, so the safety profile is covered. The description adds that the part is 'empty' and comes from the 'default template', which is useful, but it omits whether the new part becomes the active document or whether an existing open document is affected.

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. Every word (verb, resource, emptiness, template source) carries information.

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

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

An output schema exists, so return values need no explanation, and with no parameters the surface area is small. However, for a document-creation tool the description should say whether the new part becomes the active document and whether any existing document state is impacted, which it does not.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. Schema coverage is 100% and the argument object is empty, consistent with 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?

Names a specific verb ('Creates') and resource ('new empty part') and specifies the source ('default SolidWorks part template'). The resource noun 'part' cleanly separates it from new_assembly and new_drawing, though it never explicitly acknowledges 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?

No statement of when to use this versus new_assembly/new_drawing, no prerequisites (does SolidWorks need to be running?), and no note about what happens if a document is already open. The agent must infer all usage context from the tool name alone.

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

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

Annotations cover the safety profile (readOnly=false, destructive=false, non-idempotent), so the description is free to add the implicitly stateful 'last sketch' scope and the material-removal semantics of cut=True — both are genuinely useful and not in the structured fields. Minor residual: no mention that angle defaults to a full 360 revolve and that results are appended as a new feature, so it doesn't fully explain effects.

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

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

Two short sentences, front-loaded with the core action and its precondition, then the one non-obvious flag. No filler and nothing redundant with the schema.

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

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

An output schema exists so return values need no explanation; the schema documents angle bounds; the description covers the stateful precondition and the undocumented cut flag. For a 2-parameter feature-creation tool this is sufficient to call it correctly.

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

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

Schema coverage is only 50% (cut has no description), and the description compensates by explaining that cut=True removes material rather than adding it — the single most important semantic for that flag. angle_deg is already documented in the schema with bounds, so nothing further is required there.

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

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

States a specific verb and resource (revolve the last sketch) plus the geometric precondition (a construction line inside that sketch). It is clearly distinguishable from sweep/loft/extrude siblings by name and operation, though it never explicitly contrasts itself with them.

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

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

Gives real prerequisites: the sketch must be the last one and must contain a construction line, with the exact recipe (sketch_line construction=True) for satisfying that. It also explains the cut=True mode. What's missing is any explicit guidance on when to use revolve vs sweep/loft or when cut mode is preferred.

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-readonly, non-destructive, non-idempotent mutation. The description adds useful behavioral detail about thickness centering, material growth direction, and flip behavior when the rib does not reach the part.

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

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

The description is front-loaded with the core definition and then moves efficiently through the non-obvious parameter semantics. It is appropriately sized for a CAD feature tool and every sentence adds information.

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

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

Given the presence of an output schema and annotations, the description covers the key geometric behavior and most parameters. It could be stronger by briefly clarifying draft_angle_deg or the active-sketch prerequisite, but it is largely complete for correct invocation.

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

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

Schema description coverage is only 40%, so the description must compensate. It explains thickness_mm, one_side, direction, and flip_material well; draft_angle_deg is left to the schema, which does provide a basic description and bounds.

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 CAD feature, 'Rib from the last sketch', and explains the geometric basis of a rib. It is clear enough to distinguish from siblings like extrude or fillet, but it does not explicitly name alternatives or contrast its role with them.

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

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

The description implies the usage context by saying the rib usually comes from an open line between walls drawn on a mid-plane sketch. It does not explicitly say when to use this tool instead of extrude, sweep, or other feature tools, nor does it state prerequisites beyond 'last sketch'.

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

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

Beyond the annotations (which already flag destructive=true and idempotent=true), the description discloses non-obvious behavior: format is inferred from the extension, relative paths are confined to the projects folder, missing folders are auto-created, and the save is rejected on an existing file unless overwrite is True. The one gap is that it never explains what happens when path is omitted (the documented 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?

The core action is front-loaded, then path semantics, then the overwrite rule — a sensible order with no filler. The parenthetical extension list is slightly noisy but earns its place by showing the format-inference behavior concretely.

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

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

With an output schema present, return values need not be described, and annotations cover the safety profile; the description fills in the operational edges (format inference, sandboxing, overwrite rejection). The unexplained empty-path default and the ambiguous boundary with export_document are the remaining gaps.

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

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

Schema coverage is 0%, so the description must carry the full load, and it does: 'path' is explained as a save/export target whose format derives from the extension, plus relative-path confinement and folder creation; 'overwrite' is explained as a hard requirement for existing files. Both parameters gain meaning unavailable in the bare 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 ('Saves the active document') and immediately qualifies it with export semantics keyed off the file extension. It does not, however, differentiate itself from the sibling export_document, which overlaps substantially with the 'exports to that file' behavior described here.

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

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

Gives concrete preconditions for the overwrite parameter and the relative-path/projects-folder rule, which guides invocation. But it offers no guidance on when to choose this tool over export_document or why omit path entirely, leaving the main routing decision 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?

Adds real behavioral context beyond annotations: the coordinate system is model mm, and append=True accumulates into the current selection (implying default replaces it), which the schema does not encode. The hint that it can be used to 'check that a point really lies on an edge' also implies it may fail to find a match, though the failure behavior itself is never stated.

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, front-loaded with the action and coordinate convention, then the parameter behavior, then the usage caveat. No filler or restatement of the tool name.

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

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

An output schema exists, so return values need not be explained; the description covers units, selection-state side effect, and the practical caveat. The only gap is what happens when no edge passes through the point (error vs. empty selection), which matters for a tool sold as a validation check.

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 0% (bare titles like 'X Mm'), so the description must carry the burden — and it does, establishing that the three coordinates are a single point in mm model coordinates and defining append's effect. It omits what happens when append is omitted (default false) and any tolerance for the point match.

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

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

Opens with a specific verb and resource ('Selects the edge of the part') plus the selection criterion ('passing through the point (x, y, z)'). This is enough to distinguish it from sibling select_face_at_point and from sketch/feature tools without opening a schema.

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

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

Explicitly frames the use case and discourages misuse: fillet/chamfer take points directly, so this is mainly for verifying a point lies on an edge. It stops short of naming select_face_at_point as the alternative for face selection, so it isn't fully exhaustive.

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 non-destructive, idempotent, non-open-world behavior, so the safety bar is low. The description adds that coordinates are in model space and millimetres, but says nothing about behavior when no face lies at the point, or whether an existing selection is replaced or added to.

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

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

Two sentences, no filler; the operation and its units are stated first, with the prerequisite hint second. Every clause earns its place.

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

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

An output schema exists, so return values need not be described, and the tool is inherently simple with three required scalars. The remaining gap is failure-mode behavior, which would matter for an agent probing internal 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?

Schema coverage is 0% and the properties carry only titles, so the description is the sole source of semantics. It supplies the two things that matter: the units (mm) and the coordinate system (model coordinates), which prevents an agent from passing drawing or screen coordinates.

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 ('Selects the face of the part') and qualifies it by an exact geometric condition (passing through a point). The face-vs-edge distinction from the sibling select_edge_at_point is implicit in the resource name but never called out 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 concrete prerequisite workflow: use get_bounding_box first to find coordinates of the outer faces, which tells the agent how to obtain valid arguments. It does not say when to avoid this tool, e.g. when selecting internal faces or when no geometry exists at the point.

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