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

With no annotations, the description carries the full burden. It usefully discloses that it works both on previously opened documents and on new, never-saved ones, but says nothing about error behavior when a title is missing or what side effects (e.g., switching away from the current document) occur.

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 action and followed by the context. No wasted text, though the first sentence's grammar is a bit loose.

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

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

For a one-parameter, no-output-schema tool, the description covers purpose, triggering context, and title sourcing. It lacks failure-mode and state-change details, but is largely sufficient 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% and the single 'title' parameter is only typed as string in the schema. The description compensates by telling the agent where titles come from (list_documents) and that they can refer to unsaved documents, which is meaningful added value.

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: making an open document 'current again by its title', and clarifies it also handles a never-saved document. An agent can distinguish this from open_part/close_part siblings, though the phrasing 'make current' is slightly informal.

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 situates usage: 'For after open_part / close_part on another document', and points to list_documents as the source of titles. It gives a clear triggering context but no explicit exclusions or failure conditions.

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

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

With no annotations, the description carries the full burden. It helpfully discloses units (mm) and the return payload ('mass properties and dimensions'), and the face-finding behavior, but it does not state that this is an additive/material-creating operation, nor any permission or reversibility context expected of a mutation tool.

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

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

Three short, front-loaded sentences with the core action first and supporting details after; minimal waste. It is dense 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?

For a 7-parameter mutation tool with no annotations, 0% schema coverage, and no output schema, the description covers the essential geometry and even the return values. However, the additive/mutating nature and the undocumented 'name' parameter leave gaps an agent would need filled.

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 compensate. It clarifies height_mm, the (x, y, z) centring semantics, and the 'round' nature implying diameter, but leaves the diameter unit/meaning and the optional 'name' parameter (default 'Boss') unaddressed.

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 ('Grow') and resource ('round boss (standoff, peg)'), with the key geometric modifiers height_mm and a centring point. It distinguishes itself from near-siblings by noting it acts on 'ANY planar face' and tying face-finding to add_hole_on_face, though it does not explicitly separate itself from add_cylinder/add_disc.

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 reference to how add_hole_on_face locates the face gives implied guidance, and the PCB-standoff note hints at a scenario, but there is no explicit when-to-use/when-not or a named alternative tool for the same job. Usage is inferable 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?

With no annotations provided, the description carries the full behavioral burden. It discloses the creation/extrusion workflow, units in millimetres, the returned feature name, the depth dimension handle 'D1@<name>', and the dimensions structure for set_dimension. It does not mention preconditions like needing an active part, but the main behavioral contract is clearly 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?

The description is compact and front-loaded: the first sentence states the core action and method, while the second provides only high-value details about units and return values. Every sentence earns its place with no redundant 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?

Given the simple primitive shape, four parameters, and no output schema, the description is nearly complete: it covers operation, units, return values, and an integration hint for set_dimension. It could be more explicit about the active-part requirement, but the essential call context is present.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully explains that dimensions are in millimetres and maps width/height to the sketch and depth to the extrusion. However, the optional 'name' parameter is not explicitly described, and the meaning of the returned 'dimensions' array is mentioned only as output context.

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

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

The description names a specific verb and resource: 'Add a rectangular block', then details the construction method (sketch width x height, extrude by depth). This clearly distinguishes it from sibling primitive tools like add_disc, add_cylinder, and add_extruded_profile.

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

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

Usage context is implied by the 'rectangular block' phrasing, so an agent can infer it is for box-like solids. However, there is no explicit guidance on when to prefer this tool over alternatives like add_extruded_profile, nor any mention of exclusions or prerequisites.

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

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

No annotations are supplied, so the description carries the full burden. It discloses the geometric outcome ('round an arc the chamfer is a cone') and the return payload ('number of edges chamfered and the mass properties'), which is real added value, but says nothing about whether the operation mutates/marks the part destructively, permissions, or failure modes.

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

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

Information density is high and nothing is pure filler, but the second sentence is a run-on that mixes the from_face rule, an example, and a parenthetical fragment ('round an arc the chamfer is a cone') in one breath. The core action is front-loaded, but the parameter guidance is harder to parse than it needs to be.

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

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

With no output schema, the description correctly reports the return value, and with no annotations it is the only source of behavior — yet it omits the name parameter and any statement about mutating the active part. Adequate for calling it, but not complete for a 5-parameter, annotation-free mutation tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it documents distance_mm ('distance back along a face'), angle_deg's default and its dependency on from_face, from_face's meaning and format ('-z'), and the full selector grammar for edges. The name parameter is left entirely unexplained, which keeps it out of 5 territory.

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 ('Chamfer edges of the current part') and the geometry it operates on, so an agent immediately knows this is the edge-chamfering operation. It never names or contrasts with the closely related siblings add_fillet and add_full_round, which is what would have earned 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?

Provides conditional usage rules for the tool itself — 'Another angle than 45° needs from_face' and the printable-underside example at angle_deg=60 — which is genuinely helpful. It gives no guidance on when to choose chamfer over add_fillet/add_full_round or what document state is assumed, so usage is only implied relative to alternatives.

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

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

No annotations are provided, so the description carries the burden. It discloses a key behavioral trait: the axis is determined by the cylindrical face nearest to (center_x_mm, center_y_mm), and `feature_name` defaults to the last feature. However, it doesn't mention whether the operation is destructive, requires a rebuild, or what happens if no cylindrical face is found. These are gaps, but the disclosed axis-selection behavior is valuable.

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. The first sentence states the core behavior, the second explains the axis selection heuristic, and the third gives a practical example. Every sentence earns its place with no fluff.

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 tool with no output schema and no annotations, the description covers the essential semantics and provides a usage example. It doesn't specify error cases (e.g., no cylindrical face found) or whether the pattern is associative/parametric, but the core information needed to invoke the tool correctly is present.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the meaning of `count` (repeat count around 360°), `center_x_mm`/`center_y_mm` (used to find the nearest cylindrical face), and `feature_name` (defaults to last feature). This adds significant meaning beyond the raw schema, which only provides types and 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?

The description clearly states the tool's function: repeating a feature `count` times around 360° about an axis. It specifies the resource (feature), the operation (repeat/pattern), and the key parameters (count, center coordinates). It also distinguishes itself from the sibling `add_linear_pattern` by explicitly describing a circular pattern around an axis.

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

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

The description provides a concrete usage example: 'Bolt circle: drill a centre hole + one bolt hole, then pattern the bolt hole.' This implies when to use the tool and how to set it up. It doesn't explicitly state when not to use it or name alternatives like `add_linear_pattern`, but the circular-vs-linear distinction is clear from the name and description.

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?

There are no annotations, so the description must carry the behavioral burden. It discloses the construction method, the special full-cone case, and that the tool returns mass properties with a volume formula. It omits placement/orientation and failure behavior, but the core behavioral profile is clear.

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: the main action appears first, followed by the key parameter case, return value, and prerequisite. Every sentence adds useful information with no filler or redundancy.

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

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

Given no annotations, no output schema, and no schema-level parameter descriptions, the description covers the essential call context: what the tool creates, when the shape is a cone vs. frustum, what it returns, and the need for a new part. It could add placement/orientation and numeric validity constraints, but an agent can likely invoke it correctly as written.

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 does so by explaining top_diameter_mm = 0 and giving a volume formula that ties height, bottom radius, and top radius together. The optional name parameter and the rb/rt notation are not detailed, but the required geometry is interpretable.

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 creates a cone/frustum by revolving a trapezoidal profile 360°. This directly distinguishes it from sibling tools like add_cylinder, add_disc, and add_revolved_profile.

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 an explicit prerequisite ('Use new_part first') and clarifies the cone vs. frustum distinction via top_diameter_mm = 0. It does not explicitly name sibling alternatives or say when to prefer add_cylinder, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full burden. It explains the cut geometry, the coaxial flat-bottom pocket, the through-thickness clearance shank, the coordinate system sharing add_box's system, and that mass properties are returned. This gives the agent a solid behavioral model, though it doesn't mention prerequisites like an active part or irreversibility.

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. The first sentence states the core action, the second explains the geometry and use case, and the third adds the constraint and coordinate system. Every sentence adds value; 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?

Given the lack of annotations and output schema, the description covers the essential context: what is created, where, how, common use, parameter relationships, coordinate system, and return value. It could be more explicit about active-part requirements and when a simpler hole tool should be used, but it is largely complete for invoking the tool correctly.

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

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

Schema coverage is 0%, so the description must compensate. It does: clearance_diameter and cbore_diameter are semantically explained as clearance shank and counterbore pocket, cbore_depth is described, x_mm/y_mm are tied to the +Z face, and the constraint 'cbore_diameter must exceed clearance_diameter' is explicitly stated. Only the optional name parameter is not described, which is acceptable.

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

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

The description opens with a specific verb and resource: 'Cut a counterbored screw hole on the +Z face at (x_mm, y_mm).' It clearly distinguishes this from generic hole tools like add_hole or add_hole_on_face by describing the counterbore geometry, making it unambiguous what operation is performed.

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

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

The description provides clear usage context: it is for cap-head screws or heat-set inserts that need to sit flush/recessed, common for 3D-printed parts. It does not explicitly name alternatives or state when not to use it, but the use case is concrete enough to guide selection.

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

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

No annotations are present, so the description carries the burden. It discloses that the tool returns mass properties including the volume formula, and hints at state requirements with 'Use new_part first.' However, it does not describe side effects on the current part, placement/axis orientation, or failure 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?

Three short sentences, purpose first, no filler. 'The first revolve-based primitive' adds positioning context but is somewhat vague; overall it is efficient.

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 with no annotations and no output schema, it leaves important gaps: default axis/orientation, units, placement, and behavior when no part exists. It covers purpose, prerequisite, and return value, but not enough for confident invocation.

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

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

Schema description coverage is 0%, so the description must compensate, but it only gives a volume formula using r while the schema parameter is diameter_mm. It does not explain diameter_mm, height_mm, or the optional name parameter beyond their names.

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

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

States a specific action ('Create a cylinder by revolving a profile 360° about an axis') with the resource and construction method. It is clear, though it does not explicitly differentiate from sibling add_revolved_profile beyond calling itself 'the first revolve-based primitive.'

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

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

Provides a prerequisite ('Use new_part first') and implies it is the primitive form of revolve, but does not state when to choose it over add_revolved_profile or other primitives like add_disc/add_cone. No exclusions or alternative conditions 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?

With no annotations, the description carries the full burden and does well: it discloses the build orientation (+Z with flat faces at +/-Z), the return value ('Returns mass properties'), and the prerequisite. It does not describe failure modes or what happens if the part is not open, which keeps it from a 5.

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

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

Front-loaded with the core definition, then composition, defaults, return value, and prerequisite in a tight sequence. The phrase 'off it, its x and y are dimensions' is compact but slightly cryptic; otherwise 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 5-param mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers geometry, orientation, composition, defaults, return value, and prerequisite. It omits the meaning of diameter/thickness and error behavior, but is largely 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 coverage is 0%, so the description must compensate. It adds meaning for x_mm/y_mm (centre defaults to origin; off-origin they are dimensions), but says nothing about diameter_mm, thickness_mm, or name. It partially compensates for the coverage gap rather than fully closing it.

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

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

States a specific verb (Create) and resource (disc/puck/flange) and defines the geometry precisely: 'a circle extruded along +Z, centred at (x_mm, y_mm)'. This cleanly distinguishes it from siblings like add_cylinder, add_box, and add_extruded_profile.

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

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

Gives a clear prerequisite ('Use new_part first') and explains composition partners (add_hole, add_circular_pattern for bolt circles). It stops short of an explicit when-not-to-use versus add_cylinder, but the context is strong enough to route correctly.

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

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

With no annotations provided, the description carries the full behavioral burden and discloses several important traits: auto-closing the polygon, merge=False leaving a separate body, and returning mass properties with a volume formula including corner-radius effects. It does not state preconditions such as requiring an active part or document, which would be valuable for a mutation tool with no annotation coverage.

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

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

The description is front-loaded with the core operation in the first sentence, then each subsequent clause earns its place by explaining a parameter's geometry, behavior, or use case. Despite its length, there is no filler or repetition, and the density is appropriate for eight undocumented parameters.

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

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

Given the complexity (eight params, no annotations, no output schema, zero schema descriptions), the description is very complete: it covers parameters, return values, and key side effects like merge. The remaining gaps are preconditions (e.g., active part/document) and explicit routing to the on-plane/on-face 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 0%, so the description must compensate, and it does so thoroughly: points_mm format, depth_mm extrusion, corner_radii_mm modes and dimension naming, rotate_deg with about_mm and rotation direction, draft_deg sign convention and dimension name, and merge behavior. Only the trivial name parameter is left 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+resource: 'Extrude a closed polygon into a solid,' and gives the core input format. It also anchors the tool by saying the polygon uses 'first-plane coordinates, same as add_box.' However, it does not explicitly differentiate this tool from the closely named siblings add_extruded_profile_on_plane or add_extruded_profile_on_face, leaving the agent to infer the distinction from 'first-plane'.

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

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

It provides concrete use cases (brackets, profiles, polygons; draw a crank or lug straight; a moulded boss; a printable taper) and names alternatives for the merge=False case (list_bodies, combine_bodies). What is missing is explicit when-to-use guidance versus the on-plane and on-face extrusion siblings, so the agent still has to infer when this base-plane variant 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?

With no annotations the description carries the full burden. It does disclose a key constraint (points must lie on the face), the point format, corner-rounding behavior, and that it returns mass properties, but omits whether existing geometry is merged/union-ed, failure behavior if points miss the face, or any permission/rate considerations.

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

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

Front-loads the action and required inputs in the first sentence, then adds constraint/usage detail. Cross-references are compact, though the reliance on 'as for add_hole_on_face'/'as for add_extruded_profile' slightly leans on the reader knowing siblings.

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

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

For a 5-parameter, 0%-schema-coverage, no-annotation, no-output-schema tool, the description covers the core geometry params and return value but leaves the required 'face' selector and 'name' unexplained, so it is only partially 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%, so the description must compensate. It explains points_mm ([[x,y,z]] in mm on the face), depth_mm (extrusion depth), and corner_radii_mm (rounds corners), but leaves the required 'face' parameter and the 'name' parameter undocumented.

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

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

States a specific verb+resource: 'Grow a polygon boss ... out of ANY planar face,' with the required points_mm and depth_mm named. It distinguishes itself from the plane-based add_extruded_profile by scoping to 'ANY planar face,' though it does not explicitly separate itself from add_boss_on_face.

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?

Offers use-case context ('For pads, ledges and mounting blocks on an existing part') and analogizes to add_hole_on_face and add_extruded_profile, but gives no explicit when-to-use-vs-alternatives routing against the several similar siblings (add_boss_on_face, add_extruded_profile).

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

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

With no annotations, the description carries the full burden and does well: it discloses the coordinate frame for points (origin + u/v from add_plane), the direction logic (normal, reversed via reverse=True), the merge behavior, and that mass properties are returned. It omits failure/error conditions and what merge=False produces, but the core behavioral profile is present.

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

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

Front-loaded with the core action, then a dense but well-organized set of parameter notes. Every sentence earns its place; the telegraphic style ('points_mm = ...') is efficient 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?

For an 8-parameter mutation tool with no annotations and no output schema, the description covers the plane dependency, direction, merge, the reused parameters, and the return value. It is nearly sufficient for correct invocation, missing only explicit error/edge-case behavior.

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

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

Schema coverage is 0%, so the description must compensate, and it does: points_mm, depth_mm, reverse, corner_radii_mm, draft_deg, merge, and the plane are all explained, including the non-obvious 3D points-on-plane convention. Only 'name' 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 (extrude a polygon on a reference plane) and explicitly ties the plane to add_plane, distinguishing it from add_extruded_profile and add_extruded_profile_on_face. An agent can select this over its siblings without opening the schema.

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

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

The clause 'such as one add_plane made at an angle' makes the preconditions clear and points to the sibling that produces the required plane. It stops short of an explicit when-not or a direct comparison to add_extruded_profile_on_face, so it is clear context rather than full routing guidance.

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

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

With no annotations, the description carries the full burden and partially meets it: it discloses the return value ('Returns mass properties'), the geometric semantics of the half-round ends, and a volume formula. It does not state whether the extrusion is unioned into an existing body, whether it is additive vs. subtractive, or any failure conditions.

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

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

Front-loaded with the core verb and shape, then tight parameter semantics. The volume formula is arguably extra but earns its place by pinning down exactly how width/length/depth combine.

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

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

No output schema or annotations exist, and the description covers geometry and return value reasonably well. It leaves open whether the result is added to an existing solid or creates a standalone body, and gives no error or naming guidance for a 5-parameter mutation tool.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: start_mm/end_mm are [x, y] mm points that centre the half-round ends, width_mm is the tab width, depth_mm is the +Z extrusion. Only the optional 'name' parameter is left 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 (Extrude) and resource (a stadium / rounded tab, lug or link) and gives the geometric definition, which distinguishes it from cut_slot and the generic add_extruded_profile. It never explicitly names a sibling, so differentiation is by shape description only.

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

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

The description explains what the geometry is but gives no when-to-use guidance or when-not, and does not mention the obvious alternatives (add_extruded_profile, cut_slot). Usage is only implied by the shape description.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the spline is auto-closed, that volume is measured rather than analytic, and that mass properties are returned. It also notes the prerequisite of new_part. These go beyond the schema and give useful behavioral context.

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

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

Three sentences, no fluff. The first sentence states the action and inputs, the second differentiates from a sibling, and the third covers a key behavioral note and return value. 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?

No output schema exists, so the description must explain returns; it does ('Returns mass properties'). It also notes the measured volume. It lacks details on potential errors or edge cases, but for a creation tool with clear prerequisites and behavior, it is reasonably 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 coverage is 0%, so the description must compensate. It explains the format of points_mm ([[x,y], ...] in mm) and that depth_mm is the extrusion depth. It does not describe the optional name parameter, but that is minor. The main required parameters are well explained.

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: extrude a smooth CLOSED spline through points. It clearly distinguishes itself from the sibling add_extruded_profile by specifying the smooth curve nature, and mentions the inputs and output. An agent can immediately understand what it does and how it differs.

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

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

Provides a direct contrast with add_extruded_profile ('Like add_extruded_profile but...') and gives examples of use cases (cams, rounded outlines, aesthetic bosses). Also instructs 'Use new_part first.' It doesn't explicitly list when not to use other tools, but the main alternative is clearly differentiated.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses failure behavior ("A refusal names the edges the radius does not fit") and return information ("Returns the number of edges filleted and the mass properties"), though it does not discuss prerequisites or feature-creation side effects.

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

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

The description is long and dense, but it is front-loaded with the core purpose and every subsequent sentence adds operational detail about edge selection, variable radii, and propagation. It is appropriately sized for a complex CAD operation, though slightly verbose.

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

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

Given no annotations, no output schema, and 0% schema description coverage, the description supplies substantial behavioral and parameter context, including return values and failure handling. It remains incomplete only because the name parameter is never described.

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 gives rich meaning for edges, radii_at_mm, skip_shorter_mm, and tangent_propagation, but does not explain the name parameter, leaving one of six parameters 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: "Round edges of the current part with one constant radius (mm)." The operation is clear, but the description does not explicitly differentiate it from sibling tools such as add_chamfer or add_full_round.

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

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

Usage is implied by the opening sentence and extensive edge-selection guidance, but there is no explicit when-to-use guidance, no when-not-to-use conditions, and no named alternatives among the sibling tools.

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

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

With no annotations, the description carries the full behavioral burden. It adds real geometric behavior context (the round runs across the rib, not along it; radius is half the side distance; result contains width_mm), which is valuable. But it never states that this is a model-mutating operation, nor covers failure conditions or permissions, leaving the mutation nature undisclosed.

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

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

Three sentences, front-loaded with the purpose, then selection rules, then the result/area formula. Dense but each sentence earns its place; the hand-calculation formula is a small extra but aids the geometry mental model.

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?

There is no output schema, so the description's hint that the result contains width_mm is a useful partial return description. However, for a mutation tool with 0% schema coverage and no annotations, it omits whether the model is modified, the effect on existing geometry, and the meaning of the `name` parameter.

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

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

Schema coverage is 0%, so the description must compensate, and it does for most parameters: it defines what `face` denotes (the top face), how the two side faces are selected, and that (x, y, z) is a point the top face passes through. Only the optional `name` parameter goes unexplained, which is a minor gap.

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

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

The description gives a specific verb and resource: "Round a rib's top off completely: a full round fillet, as on a moulded part." This is clearly distinguished from a generic fillet by being scoped to a rib top and to a full-round profile. It does not, however, explicitly name sibling tools like add_fillet or add_chamfer to disambiguate the choice.

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

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

The description explains geometry selection (which face is the top, which are the sides) but never states when to use this versus add_fillet, add_chamfer, or other rounding tools, nor any prerequisites or exclusions. Usage must be inferred from the geometry narrative.

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

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

With no annotations, the description carries the transparency burden. It discloses the through-thickness behavior ('runs straight through the thickness'), the orientation relative to the profile face, the coordinate system with an example, and the fact that mass properties are returned. It does not cover prerequisites or failure behavior when a part is absent, but the essential runtime behavior is clear.

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

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

Two sentences, front-loaded with the main action and geometry, with supporting coordinate detail kept to a second sentence. 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 simple hole primitive, the description covers geometry, orientation, coordinate frame, and return value, and the optional name has a schema default. The exact mass-properties payload is unspecified because no output schema exists, and no alternative-selection guidance is given, leaving minor 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 compensate. It adds real meaning to x_mm and y_mm ('share add_box's system... centre of a 40x20 profile is x=20, y=10'), but diameter_mm receives no constraints or unit clarification beyond its name, and the optional name parameter is ignored.

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 operation ('Cut a circular through-hole') and locates it in the part geometry ('at (x_mm, y_mm), through the part's depth axis'). The 'through-hole' and 'depth axis' wording distinguishes it from sibling hole variants like add_counterbore_hole and add_hole_on_face even without naming 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?

Usage context is implied by the geometry described: a circular through-hole along the depth axis in the same coordinate system as add_box. It never states when to choose this over add_counterbore_hole/add_hole_on_face or notes prerequisites such as a part already existing.

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

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

With no annotations, the description carries the full burden and does well: it defines through-all vs blind behaviour via depth_mm, explains the direction-string semantics, and states what is returned (mass properties and dimensions). It omits error/failure behaviour and permission needs, but the mutation semantics are well disclosed.

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

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

Three dense, front-loaded sentences with no filler; the primary action leads and the face/depth details follow. Slightly compact given the number of concepts packed in, but 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 7-parameter mutation tool with no annotations and no output schema, the description covers the geometry semantics and even the return value. Minor gaps remain around name and diameter, but an agent could call this correctly from the description alone.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it enumerates the face direction strings, ties x/y/z to a 3D centre point in mm, and explains depth_mm as null-for-through vs a blind depth. It does not clarify diameter_mm or the name default, but the geometry-critical parameters are covered.

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 (drill) and resource (round hole) with a clear scope: on ANY planar face, centred at a 3D point. It does not explicitly differentiate itself from sibling tools add_hole, add_hole_wizard, or add_counterbore_hole, so an agent must infer 'on_face' means anchored to an arbitrary planar face.

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 usage context: pocket floors and steps work too, and blind holes suit heat-set inserts and screw pilots. However, it never says when to pick this over add_hole / add_hole_wizard, so alternative selection is left to inference.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose useful traits: through-all vs depth_mm termination, that thread='modeled' cuts a real printable thread rather than SolidWorks' cosmetic one, and that it returns standard sizes plus mass properties. It omits any statement about mutating the active part, permissions, or reversibility, so it is only partially adequate.

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 dense but front-loaded, leading with the tool's identity before enumerating options. Line breaks group related parameters sensibly; a couple of clauses (e.g. thread='modeled') are long but each carries information 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?

For a 10-parameter mutation tool with no annotations and no output schema, the description covers geometry and sizing well and even mentions the return payload. It still lacks usage guidance, the meaning of name, and any indication of side effects on the part, so it 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%, so the description must compensate, and it largely does: it explains kind values (clearance/counterbore/countersink/tapped with their ISO standards), size format ('M3'), fit options, thread behavior and depth semantics, plus centring on the face at (x,y,z). Only name is left unexplained, so it nearly covers all 10 parameters.

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 adds an ISO Hole Wizard hole sized by standard tables, which is more precise than the generic sibling add_hole and distinct from add_counterbore_hole. However it never explicitly names or contrasts those siblings, so differentiation is inferential rather than stated.

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

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

There is no when-to-use / when-not-to-use guidance and no mention of alternatives such as add_hole, add_counterbore_hole or add_hole_on_face. The text is almost entirely parameter semantics, leaving the agent to infer selection context on its own.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that the tool returns mass properties and that feature_name defaults to the most recently added feature, which is useful. However, it does not mention that the operation modifies the part, what happens on invalid feature names, or any potential side effects, leaving gaps in transparency.

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 efficient: a one-sentence purpose statement followed by parameter details. It front-loads the core operation and every sentence contributes useful information—no filler, digressions, or redundant repetition 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?

Given 4 parameters, no annotations, and no output schema, the description covers all parameters and explicitly states the return value (mass properties). It is largely sufficient for an agent to call the tool correctly. However, it omits explicit statements about model mutation and failure conditions when no feature exists, which would be valuable for full completeness.

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 is the sole source of parameter meaning. It explains all four parameters: count (times), spacing_mm (distance apart), direction (with examples like '+x'/'-x'+y'), and feature_name (with default behavior). This adds substantial semantic value beyond the bare schema, making correct invocation feasible.

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

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

The description clearly states a specific operation: 'Repeat a feature `count` times, `spacing_mm` apart, along a direction.' It names the resource (feature) and key parameters (count, spacing, direction). The linear nature and direction format (+x/-x/+y) implicitly distinguish it from the sibling add_circular_pattern, making the tool's purpose unambiguous.

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

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

The description provides parameter usage hints (direction format, feature_name defaulting to most recently added feature) but does not explicitly state when to use this tool versus alternatives like add_circular_pattern. It lacks any exclusions, prerequisites, or guidance on when not to use it, leaving the agent to infer usage from the name and context.

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

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

With no annotations, the description carries the full load and does so well: it discloses that 2 profiles give a ruled transition while 3+ blend smoothly, that centers may wander, the vertex-order twist hazard, and that the tool returns mass properties. It does not state permissions or whether the operation is reversible, which keeps it from a 5.

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

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

Purpose is front-loaded in the first clause, and every following sentence adds a distinct constraint (ordering, length, twist). The heavy parenthetical asides make it denser than ideal, but no sentence is filler.

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

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

For a complex geometry tool with no annotations and no output schema, the description covers inputs, ordering rules, the ruled-vs-smooth distinction, and the return (mass properties). It is nearly complete, missing only failure modes or unit/permission caveats.

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 compensate and it does: profiles_mm is explained as either a polygon of [x,y] pairs in Front-plane coords or a round {center_mm, diameter_mm} section, and heights_mm is described as a strictly increasing +Z offset list of equal length starting at 0.

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 (Loft/blend) and resource (closed profiles on parallel planes along +Z), with enough detail to distinguish it from siblings like add_swept_profile and add_revolved_profile without opening the schema.

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

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

Gives one concrete prerequisite ('Use new_part first') and implicitly frames the tool as a solid-creation step, but never states when to choose loft over the neighbouring sweep/extrude/revolve tools. Usage is implied rather than routed.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the verification/rollback semantics ('The result is measured back after the rebuild; a mate that does not hold is removed and the components are put back') and the dimension-driving workflow. This is non-obvious failure behavior an agent could not infer from the schema.

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

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

The core action is front-loaded and most sentences are information-dense, but the nested parentheticals and the extended angle-wrap discussion ('past 180 and below 0') push length higher than strictly necessary. Still, very little is padding.

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

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

For an 8-parameter assembly-mate tool with no output schema, no annotations, and 0% schema coverage, the description covers selection syntax, valid mate types, modifiers, follow-up tools, return value ('its dimension'), and failure handling. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: comp_a/comp_b naming conventions, four distinct face_a/face_b selection syntaxes (direction with ':inner', list_faces index, '#5', '@x,y,z'), the enumerated mate_type values with distance_mm/angle_deg applicability, and flip's effect on the solution. Only default values go 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 first sentence gives a precise verb and resource: 'Mate a face of one component to a face of another.' It clearly distinguishes this assembly operation from siblings like delete_mate, suppress_mate, and set_component_transform, so an agent can identify it without schema inspection.

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 establishes when this tool applies (positioning two components via face mates) and routes the agent to follow-on tools: 'drive it with set_dimension, or step it with check_motion.' It does not explicitly state when NOT to use it or contrast it against alternatives like set_component_transform, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the merge behavior of a body mirror, the failure mode and its guarantee ('Fails, leaving the part as it was, when a copy would land outside the part'), and the resulting dimension name 'plane_offset'. It does not state prerequisites such as requiring an open part or the effect on pre-existing features.

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?

Content is front-loaded and every sentence carries information, but the plane/offset explanation is dense and split awkwardly across line breaks, forcing a re-read. Slight tightening would improve it without losing substance.

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

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

No output schema and no annotations, so the description must stand alone, and it covers inputs, merge semantics, failure behavior, and the produced dimension. The main remaining gap is the absence of any precondition (e.g., an open part) or interaction with existing 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?

Schema coverage is 0%, so the description must compensate and largely does: it explains that plane accepts 'front'/'top'/'right', a z/y/x offset, or another plane name moved along its normal, that offset_mm is that displacement, and that features takes list_features names whose copies follow their seeds. Only the 'name' parameter is left 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 opens with a specific verb and resource ('Mirror features, or the whole body') and immediately bounds the scope by plane type and offset. An agent can distinguish this from the pattern siblings (add_linear_pattern, add_circular_pattern) 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?

It gives a concrete usage scenario: 'Without features the body is mirrored and merged: model half of a symmetric part, mirror it about the face where the halves meet.' That tells the agent when the no-features path applies, but no alternative tool is named for cases where mirroring is not the right operation.

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

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

With no annotations, the description carries the full burden and does well: it discloses transform order ('turn first, then offset'), the right-hand-rule convention, and the exact return contents (name, origin_mm, normal, x_axis, y_axis). It stops short of stating side effects on the document or error behavior for invalid inputs.

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 lead sentence front-loads purpose, then details follow. It is dense but each clause (axis conventions, transform order, return formula) earns its place; heavier parenthetical nesting slightly hurts scannability.

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

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

For a 5-parameter tool with no output schema and no annotations, the description supplies the missing parameter meanings, the return schema, and construction semantics. Only error/edge-case behavior is unaddressed, which is a minor gap for a plane-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 0%, so the description must compensate, and it largely does: it defines base (front/top/right or a plane by name), offset_mm (distance along the normal), angle_deg (turn amount), and about='x'/'y'/'z' with which axes each base holds. The 'name' input parameter is only referenced obliquely via the return value, leaving mild ambiguity.

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

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

States a concrete verb+resource ('Make a reference plane to sketch on') and immediately distinguishes its two construction modes (offset vs. turned). An agent can tell exactly what this builds and how it differs from siblings like add_sketch or add_extruded_profile_on_plane.

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

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

The description explains how to configure the two modes in detail, but never states when to choose add_plane over alternatives or the conditions/prerequisites for each mode. Usage is implied rather than prescribed, which is adequate but leaves selection reasoning to the agent.

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

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

With no annotations, the description carries the full burden and does well: it discloses the auto-close/spin behavior, the default 360° angle, the hard constraint that the profile may not cross the axis, and that it returns mass properties. It stops short of document-state requirements beyond 'use new_part first' or error 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?

Front-loaded with the core action, then builds geometry semantics in dense but useful sentences. Slightly long for a tool description, but nearly every clause carries information the schema cannot.

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?

Five parameters at 0% schema coverage and no output schema are fully accounted for: input formats, defaults, constraints, geometry outcomes and the returned mass properties are all stated, leaving nothing an agent needs 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 0%, so the description must compensate, and it does: it specifies the two distinct profile_mm formats ([r,z] radial vs [x,y] absolute) tied to the presence of axis_mm, explains axis_mm as a two-point line, and notes angle_deg defaults and corner_radii_mm corner-only-on-profile 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 and resource ('Revolve a closed profile on the Front plane about an axis in it'), and the geometry described (spun profile, axis semantics) clearly separates it from add_extruded_profile, add_swept_profile and add_lofted_solid.

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

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

Gives clear selection context (points on the axis yield solids/shafts, an offset profile yields a ring) and a prerequisite ('Use new_part first'), but never names an alternative sibling or states when not to use this in favor of extrusion/sweep/loft.

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

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

With no annotations, the description carries the full burden, and it does so well: it explains how the rib grows toward toward_mm until meeting the part, how thickness is applied, and that it returns mass properties. It doesn't mention prerequisites like an active part or failure modes, but it discloses the key behavioral and return characteristics.

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 well-structured and front-loaded with the purpose, then parameter semantics, then return behavior. Each sentence provides distinct value, and the mass-properties formula earns its place because it tells the agent what result to expect.

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 no annotations, no param descriptions, and no output schema, the description is remarkably complete for a CAD primitive tool. It covers the geometry, all key parameters, and the return. Minor gaps are the lack of an explicit prerequisite that a part must be open and no discussion of failure conditions if the rib never meets the part.

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%, yet the description explains almost every meaningful parameter: start_mm/end_mm as [x,y] endpoints, z_mm as plane height, toward_mm as the fill direction, and thickness_mm as the rib thickness. It also ties coordinates to add_extruded_profile, which helps an agent understand the expected format.

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

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

States a specific verb and resource: adds a straight stiffening rib/gusset in a plane parallel to the Front plane. The geometric detail and the mention of 'rib/gusset' differentiate it clearly from generic extrusion or sweep siblings.

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

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

Usage is implied by the clear domain language ('stiffening rib / gusset'), and the coordinate reference to add_extruded_profile gives some context. However, it does not explicitly state when to prefer this over alternatives like add_extruded_profile or add_swept_profile, nor does it mention exclusions.

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

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

With no annotations, the description carries the full burden. It discloses that the tool modifies geometry (hollows the part) and returns mass properties, which is important context. However, it does not mention destructive nature (permanent modification), potential side effects like altering existing features, or error conditions. It adds some value beyond the schema but has gaps.

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

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

The description is concise (two sentences) and front-loads the core operation. It efficiently explains the open_face parameter in the second sentence. No wasted words, though it could be slightly more structured, but it's appropriately sized for the tool's complexity.

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

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

The description covers the primary operation and parameter semantic, but lacks details on return format (even though output schema is absent), prerequisites (e.g., must be a solid part), and edge cases like multiple faces or non-cuboid shapes. For a tool with 2 parameters and no output schema, it is functional but misses some completeness.

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 description coverage is 0%, so the description must explain parameters. It does: open_face is clearly described with possible values and meanings, and thickness_mm's purpose is implied by 'wall of thickness_mm'. The description provides meaning that the schema lacks, making it highly valuable for correct parameter usage.

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 ('Hollow') and the resource ('current part'), and clarifies that it transforms the part by creating a wall of given thickness. It also explicitly defines the open_face parameter's effect, making the tool's purpose unambiguous. This distinguishes it from sibling modeling tools like add_box or add_shell's related operations.

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 for hollowing operations but does not specify when to use this versus alternatives like cut_profile or add_hole. It lacks explicit context about part requirements (e.g., must be a solid with at least one face) or scenarios where a different tool is more appropriate. However, it does convey the core operation clearly enough for an agent to infer basic usage.

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

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

With no annotations, the description carries the full burden and does so well: it defines the plane-relative (u, v) coordinate mapping per plane, the start_mm anchor, closure rule, automatic tangent relations, and the naming of generated dimensions (x<i>/y<i>, r<k>). This is the rich behavioral context an agent needs to compose a valid 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?

Dense but front-loaded with the core action first, then coordinate conventions and segment grammar. Every sentence carries construction detail; the size is justified for a geometrically complex tool, though it reads as a single block.

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

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

No output schema exists, yet the description explains the return (a fully defined sketch whose plane axes and points_mm are accessible) and the follow-up tools. Only the undocumented 'name' parameter and the absence of any error/edge-case guidance leave minor 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 compensate, and it documents plane, start_mm, and the segment format in detail. The 'name' parameter is left entirely undocumented in both schema and description, keeping it from a 5.

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

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

States a specific verb and resource (draw a sketch of lines, arcs and splines on a plane) plus scope and downstream intent (to extrude or cut). This clearly separates it from neighbors like add_extruded_spline, add_swept_profile, and read_sketch.

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

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

Explicitly routes the agent forward ('Then extrude_sketch / cut_sketch the returned sketch') and points to add_plane for named planes. It gives a clear context for use but does not state when not to use this or contrast it against other profile-creation tools.

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

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

With no annotations provided, the description carries the behavioral burden and discloses useful traits: the round profile is auto-generated perpendicular to the path, smooth creates a spline, bend radius is conditional, and it returns mass properties via pi r^2 x path_length_mm. It stops short of covering error conditions or document-context requirements beyond 'Use new_part first'.

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 action and resource, then explains the key parameters and return value in a few dense sentences. Every sentence adds useful instruction or behavior; no filler or repetition of the schema.

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

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

For a feature-creation tool with no annotations and no output schema, it covers the core geometry, parameter semantics, prerequisite part context, and return-value formula. Minor gaps remain around the optional name parameter and explicit failure modes, but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: path_mm is [[x, y], ...] in mm as the centreline, diameter_mm is the outer diameter, bend_radius_mm is required when the path turns, and smooth runs a spline. Only the optional name parameter is not described, which is a minor gap.

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

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

States a specific verb and resource: sweep a circular profile (pipe/tube/rod) along a 2D path on the Front plane. It is clear what solid is created and its geometric scope, but it does not explicitly differentiate itself from the generic sibling add_swept_profile or other sweep/profile 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?

Provides prerequisite context ('Use new_part first') and conditional guidance for bend_radius_mm and smooth, which implies when the tool applies. However, it gives no explicit alternatives or when-not-to-use guidance versus siblings such as add_swept_profile or add_cylinder.

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

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

With no annotations, the description carries the burden and does so well: hard constraints on the input ('MUST start at the origin heading +X', profile perpendicular there), the body it creates, the volume relation, and the return value ('Returns mass properties'). It omits failure modes and whether the sweep is additive/merges with existing bodies, so not a full 5.

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

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

The capability and its use cases are front-loaded, and the dense notation is justified by the geometry it encodes. The parenthetical coordinate mapping is information-heavy but not padded; slightly telegraphic for a first read.

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

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

For a 5-param geometry tool with no annotations and no output schema, it covers geometry conventions, constraints, rounding behaviour, and a return-value note, plus the ordering prerequisite. Remaining gaps (typical error cases, how the new body interacts with existing ones) are moderate but not blocking.

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, and it largely does: profile_mm and path_mm orientations, planes, coordinate mappings, and units are given, and bend_radius_mm / corner_radii_mm are explained in terms of the behaviour they change. Only 'name' is left unaddressed, which is self-evident.

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 ('Sweep an arbitrary closed PROFILE along a 2D PATH') and then scopes it with concrete use cases (rails, gaskets, trim, channels) that separate it from the sibling add_swept_pipe (round pipe) and swept_region. An agent can pick this tool without opening the schema.

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

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

Explicitly says when to use it ('For non-round extrusions along a path') and gives a prerequisite ('Use new_part first'). It implies rather than names the alternative (add_swept_pipe for round sections), so no exclusion rule is spelled out, keeping it short of a 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the per-face orientation behavior, the font-installed prerequisite, and the return value (text_area_mm2). It omits permission/error behavior and mutation reversibility, but for a local CAD modeling op this is strong 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?

Front-loaded with the core verb and use case, and each sentence carries real information. The orientation clause is dense but earns its place by preventing misplacement; minor redundancy between the corner and 'two dimensions' phrasing costs a point.

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

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

No output schema exists, yet the description supplies the return value, and for a 10-param tool at 0% schema coverage it documents most semantics plus orientation behavior. The undocumented face/name parameters and the z-axis ambiguity are the only material 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 compensate and does explain x/y/z, height_mm, depth_mm, emboss and font semantics. However it leaves 'face' and 'name' undocumented and introduces confusion by first describing a three-coordinate corner then stating 'the position is two dimensions ('x','y')' while z_mm is required.

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 ('Engrave text into ANY planar face, or emboss it') that an agent can distinguish from every sibling, none of which touch face text. The parenthetical use case (labels, version numbers) sharpens intent further.

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

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

Gives concrete when-to-use guidance by explaining which faces yield readable text ('put labels on the top or front') and how the emboss=True variant is selected. No explicit alternatives are named, but no sibling overlaps this operation, so the practical routing advice is the useful part and it is 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states that the thread runs into the material, is right-handed, has validation against SolidWorks' thread profiles, and returns mass properties plus thread dimensions. It does not discuss reversibility or side effects, but it gives a solid picture of what the operation does.

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 dense but every sentence earns its place: purpose first, then parameter semantics, then usage prerequisites, then return value. There is no filler or repetition of schema titles.

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 tool with no annotations and no output schema, the description covers the essential context: coordinate convention, length direction, handedness, external/internal prerequisites, and return information. An agent has enough to call it correctly without additional inference.

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

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. It explains the size format with examples and validation, the coordinate meaning (centre of the circular edge), the internal boolean (hole vs rod), and length_mm. Only 'name' is left to the schema, and its default makes it self-explanatory.

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

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

The description names a specific verb ('Cut'), a specific resource ('a real, printable ISO metric thread'), and the mechanism ('SolidWorks' own Thread feature'). This clearly distinguishes it from siblings like add_hole and cut_profile, which are different operations on different geometry.

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

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

The description gives clear usage context: where the thread starts, how far it runs, and the prerequisites for external versus internal threads (nominal diameter for rods, pre-drilled minor diameter for holes). It does not explicitly name alternative tools or state when not to use it, but the conditions are concrete and actionable.

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

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

With no annotations, the description carries the behavioral burden and does well: it defines the unit (mm^3), excludes touching faces with a concrete example, and explains the meaning of count == 0. It stops short of stating whether the tool is read-only or how strict the overlap tolerance is, but the core behavior is clear.

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

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

Three short, well-structured sentences lead with the main purpose, add the critical touching-face exclusion, and end with the count interpretation. Every sentence earns its place and no unnecessary details are included.

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

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

For a zero-parameter analysis command, this is complete: an agent knows what is returned (overlapping component pairs and volumes), how to interpret count, and what edge case (touching faces) is deliberately excluded. No output schema exists, but the description covers the essential return contract.

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 and the schema accurately reflects that, so there are no parameter semantics to document. The description still adds value by describing the output semantics (per-pair overlap volume and clash count), which is useful in the absence of an output schema.

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

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

The description opens with a specific verb and resource: 'Report component pairs whose solids overlap, with the volume in mm^3.' This clearly identifies it as an interference/clash analysis tool and separates it from the creation/getting siblings such as add_box or get_mass_properties, which do not report pairwise 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?

It implies this is the tool to use for clash detection and gives an interpretative rule (count == 0 means clash-free), but it never explicitly states when to call it versus alternatives or what conditions apply, such as requiring an open assembly or a prior rebuild.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the return structure (per-step overlapping pairs with volumes/distances, summary with clash_free and minimum distance), the reversal side-effect ('The dimension goes back to its value afterwards'), and the failure mode when a mate is broken. It omits performance/timing characteristics, so not quite a 5.

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

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

The purpose is front-loaded and the rest is dense but earns its place. Some sentences run long and blend input-parameter guidance with output description, which slightly hurts scanability, but there is little dead weight.

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

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

With no output schema and no annotations, the description explains returns, the reversal side-effect, parameter formats, and the refusal condition, which is close to complete. It could say a bit more about cost/runtime for a sweep over many values, but nothing essential 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 0%, so the description must compensate and it does for all three parameters: dimension_name (a mate dimension, with the sub-assembly syntax 'D1@Angle1@Leg-1'), values (degrees vs mm with a concrete example array), and the distances pair format. This fully covers the gap.

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

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

States a specific verb+resource: 'Step a joint through its range and check the assembly at every step.' This is clearly distinct from a static clash tool like check_interference, but the description never names that sibling, so the differentiation is left implicit.

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

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

Gives a real precondition (refused while a mate is broken, and why) and explains how to obtain the required dimension_name from add_mate. It lacks an explicit statement of when to prefer this over a static interference check, so it stops short of full routing guidance.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it explains overhang detection, bed-contact exemption, the min_wall_mm scan through material, the edge-vs-wall caveat, and the returned per-face measurements. It does not mention computational cost or side effects, but for a read-only analysis tool this is strong 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?

The description is dense but front-loads purpose and then adds necessary technical detail. Most sentences earn their place by clarifying non-obvious behavior, though the stream-of-consciousness style and parentheticals make it slightly harder to scan than ideal.

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

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

Given the complexity of printability analysis, zero annotation coverage, and no output schema, the description is nearly complete: it explains what is measured and roughly what is returned. It could more fully specify the output structure or field names, but an agent can call it correctly from this text.

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 and largely does: `up` is illustrated as '+z', '-y', etc.; `overhang_deg` is defined with the 90-degree flat-ceiling example; and `min_wall_mm` is given practical meaning (e.g. two nozzle widths) plus measurement behavior. It stops short of full unit/format detail for every return field.

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?

Starts with a specific verb and resource: 'Check the current part for 3D printing, built along `up`'. It clearly distinguishes itself from generic geometric queries and siblings like check_interference by defining the printability domain (overhangs, bed contact, thin walls).

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 ('Check the current part for 3D printing') and explains how optional parameters affect checks, but it does not explicitly say when to prefer this tool over alternatives such as check_interference or measure_distance. Usage is inferable but not routed.

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

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

With no annotations, the description carries the full burden and does disclose key behavior: the operation does not save, it targets the current document, falls back to SolidWorks' active document, and refuses when unsaved changes exist. It omits error/return behavior and how the 'save' parameter changes outcomes.

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

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

Front-loads the core action in the first clause, then appends the edge case. Two short sentences with little waste, though the second paragraph is somewhat niche for its placement.

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

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

No output schema or annotations, so the description must stand alone. It covers the main action and the no-document fallback but leaves the 'save' parameter's semantics undefined, which is a meaningful gap for an operation whose main risk is unsaved data loss.

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 'save' boolean is undocumented. Worse, the description flatly says it closes 'without saving', which implies save is always false and leaves the save=true behavior unexplained, creating tension with the parameter's existence.

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 ('Close') and resource ('current part or assembly') with clear scope, and the parenthetical about export/save distinguishes it from the save_part/export siblings an agent might otherwise pick.

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

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

Gives actionable context: close without saving, export/save first if needed, and the fallback behavior when no document is open. It implies a when-not condition (only closes the active doc when it has no unsaved changes) but does not explicitly name alternative tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses operation outcomes and the return value ('mass properties and the bodies left'), but it does not state whether the operation mutates or consumes source bodies, permission requirements, or reversibility.

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

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

The description is front-loaded with the core action and resource, then efficiently explains operation modes and defaults. Every sentence contributes necessary invocation context with no filler.

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

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

For a 4-parameter tool with no annotations, no output schema, and no schema descriptions, the description is largely complete: it covers purpose, operation semantics, parameter meaning for three of four parameters, and return content. It omits the `name` parameter and mutation/safety 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 must compensate. It explains `main` as a `list_bodies` name, defines operation values (`add`, `subtract`, `common`), and clarifies `tools` as body names defaulting to every other body. The `name` parameter is left undocumented, preventing 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?

States a specific verb and resource: combines solid bodies into `main`. It also defines the three operation modes (`add`, `subtract`, `common`), making the tool's core purpose unambiguous and distinct from sibling body operations like `split_body`.

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

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

The description explains what each operation does and that `tools` defaults to every other body, which implies usage for combining bodies. However, it does not explicitly say when to use this tool versus alternatives such as `split_body` or when to avoid it.

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

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

With no annotations, the description carries the full burden. It discloses useful behavior: what offset_mm does and that the output is per-section pairs plus worst differences, compensating somewhat for the missing output schema. However, it does not state whether the operation is read-only or has side effects, nor any permission/state requirements.

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

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

Front-loads the core action, then adds interpretation and return-value notes in two short paragraphs. Every sentence carries information; only slight density/crypticness in the interpretation sentence costs it a point.

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

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

For a 5-parameter comparison tool with no annotations and no output schema, the description usefully covers the return shape and offset behavior, but leaves axis, heights_mm, frame, and path undefined and omits side-effect/permission context. Adequate but with clear 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% and there are 5 parameters, so the description must compensate. It only clarifies one parameter (offset_mm as [dx, dy, dz] moving the mesh into the part's frame); path, axis, heights_mm, and frame semantics remain entirely 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 and resource: comparing the current part's cross-sections against a reference mesh's at matching heights. This clearly distinguishes it from construction siblings, though it does not explicitly contrast itself with the related slice_mesh tool. An agent can tell what it does without opening the schema.

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

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

The description explains how to interpret results (different area = misread feature; equal areas = shifted frame) but never says when this tool should be chosen over alternatives or what preconditions apply (e.g., mesh must exist, part must be loaded). No when-to-use or when-not guidance is given.

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

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

With no annotations, the description carries the full burden and does well: it discloses the through-all default when depth_mm is omitted, how the target face is identified, that the rim follows arcs and splines, that interior holes are preserved, that rim/depth become dimensions, and that mass properties are returned. It omits editability/reversibility of the resulting feature, so it falls short of a 5.

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

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

Front-loads the core action and constraint in the first sentence, then layers geometry and return-value details. The parenthetical about the I-beam/tray/frame example is slightly digressive, but nearly every clause carries usable information.

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

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

For a 7-parameter, no-annotation, no-output-schema geometry tool, the description covers the face selection, depth default, outline behavior, and return values ('Returns mass properties'), which is most of what an agent needs. It could still say more about the feature's post-creation lifecycle (edit/suppress/delete).

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 compensate, and it does for most parameters: face, the (x, y, z) point used to select it, rim_mm, and depth_mm's null-means-through-all semantics. Only the `name` parameter (default 'Pocket') is left unexplained, a minor gap against a 7-parameter 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 ('Pocket a planar face') plus the defining geometric constraint (rim rim_mm wide along the outline). This distinguishes it from the neighboring cut_profile, cut_profile_on_face, and cut_slot siblings, which produce different geometry.

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 use-case context (recessed web of an I-beam, tray, frame) and a default behavior (depth_mm omitted = through all), which implies usage. However, it never explicitly says when to prefer this over cut_profile_on_face or cut_slot, nor states prerequisites such as the part needing an open planar face.

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

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

With no annotations, the description carries the full burden and does well: it discloses the critical default that omitting depth_mm cuts all the way through, that the polygon is auto-closed, and that it returns mass properties. Missing only permission/body-context behavior, which is minor here.

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

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

Front-loads the core action and format, then layers behavior. Efficient overall, though the parenthetical about 'notches at +/-60 degrees around a pivot' referencing add_extruded_profile is slightly cryptic and could confuse.

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

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

For a 6-param, zero-coverage, annotation-free tool it covers nearly all parameters and key behaviors, and even notes the return value despite no output schema. Adequate to call the tool correctly.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: it documents points_mm syntax ([[x,y],...] in mm), depth_mm blind-vs-through behavior, corner_radii_mm rounding, and rotate_deg/about_mm rotation. Only 'name' is left 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, resource, and scope: 'Cut a polygonal pocket/slot from the +Z face.' The '+Z face' scope helps separate it from cut_profile_on_face and cut_profile_through_plane, but it never names those siblings to make the distinction explicit.

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

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

'For pockets, slots, cutouts' gives a usage hint but doesn't say when to prefer this over near-identical siblings like cut_offset_pocket, cut_slot, or cut_profile_on_face. Usage is implied rather than delineated.

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

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

With no annotations, the description carries the full burden and does disclose meaningful mechanics: the points must be coplanar on one face, the face is inferred from them ('found through them'), and depth_mm controls blind vs through cutting. It also names the return value (mass properties). Gaps remain on failure modes (e.g. non-coplanar points or an unfindable face), but the core behavior is well covered.

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

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

Front-loads the core action and scopes the required parameter early, then layers the face/depth mechanics. Mostly tight, though the inline parameter definitions create a slightly dense run-on that could be cleaner.

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

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

For a 5-parameter mutation tool with no annotations and no output schema, the description covers the essential inputs, the blind/through behavior, and the return value ('Returns mass properties'). It is complete enough to invoke correctly, missing only edge-case/error behavior.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it documents points_mm's format as [[x,y,z]] in mm, gives valid face strings ('+x'/'-x'), explains depth_mm's blind-vs-through behavior, and clarifies corner_radii_mm. Only 'name' is left unexplained, a minor gap for a label parameter.

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

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

States a specific verb and resource ('Cut a polygon pocket/slot on ANY planar face') with explicit scope ('ANY planar face'). It is clearly separable from siblings like cut_profile, cut_profile_through_plane, and add_extruded_profile_on_face, and the 'side pockets/cutouts' phrase further narrows its domain.

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

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

Gives clear usage context ('For side pockets/cutouts') and the key selection rule (cut blind by depth_mm or through when omitted), plus a pointer to add_extruded_profile for corner-radius semantics. It stops short of explicitly stating when to prefer cut_profile or cut_profile_through_plane instead, so no 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?

With no annotations, the description carries the full behavioral burden and does well: it discloses the default that omitting depth_mm cuts through all in both directions, that depth_mm is a total centered on the plane, and the semantics of keep_inside and corner_radii_mm. It even notes the return ('mass properties'). It does not cover permissions or reversibility, but for a geometry cut that is acceptable.

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

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

Purpose is front-loaded in the first sentence, then parameters and usage details follow. The layered per-parameter notes are dense but each earns its place; the keep_inside example is a slight verbosity but clarifies an otherwise ambiguous flag.

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

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

For a 6-parameter, no-annotation, no-output-schema mutation tool, the description covers purpose, plane/point conventions, default behavior on omitted depth, the keep_inside workflow, and the return value. An agent has everything needed 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 0%, so the description must teach the parameters, and it explains plane naming and the plane-coordinate implication ('x = 0 for right'), that points_mm are 3D points ON the plane, and how depth_mm/keep_inside/corner_radii_mm behave relative to add_extruded_profile. Only the 'name' parameter goes 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 first sentence names a specific verb and resource ('Cut a polygon sketched on a reference plane') and pins down the distinguishing behavior of the operation: symmetric about the plane, cutting through in both directions. That geometric specificity separates it from cut_profile, cut_profile_on_face, and cut_sketch without the agent having to open schemas.

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

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

It supplies concrete usage context ('For shapes seen from the side: wedges, windows, symmetric recesses') and a worked keep_inside workflow ('extrude the front view, cut the side view... the 3D shape both views agree on'). It stops short of naming an alternative tool or explicitly stating when-not to use this, so it lands just below the top.

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

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

No annotations are provided, so the description carries the full burden. It discloses mutation into the body, default through-all behavior when depth_mm is omitted, direction relative to the sketch normal, reverse handling, and that mass properties are returned. It omits failure modes or dependencies, but coverage is strong.

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 concise and front-loads the core action. The line breaks are somewhat awkward, but every clause contributes operational information and 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?

With no output schema, mentioning that it returns mass properties is helpful. Core behavior and the key direction/depth parameters are covered, though the optional name parameter and sibling-tool routing remain unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for sketch (by name), depth_mm (deep or through all), and reverse (when to set True), but never explains the name parameter or its default 'Cut', leaving partial compensation.

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

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

States a specific verb and resource: cutting an existing sketch of the current part into the body. It clearly is not a generic process tool, but it does not explicitly distinguish itself from sibling tools such as cut_profile or cut_profile_on_face.

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

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

Provides operational conditions for parameters, e.g. through-all when depth_mm is omitted and reverse=True for a plane with the part in front of it. It does not explain when to choose this tool over sibling cut operations, so usage guidance remains implied rather than explicit.

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

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

With no annotations, the description carries the behavioral burden and does so well: it explains blind versus through cuts based on depth_mm, clarifies coordinate/orientation semantics, and states that mass properties are returned. It does not mention prerequisites or reversibility, but core cut behavior is transparent.

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, starting with the operation and face, then defining geometry parameters, then covering depth behavior and return value. Every sentence carries necessary information with no filler.

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

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

For a tool with no annotations and no output schema, the description covers the essential geometry, defaults, and return behavior. It is slightly incomplete only in not stating the prerequisites (e.g., an active part or face context) and not differentiating from overlapping cutting tools, but an agent can invoke it correctly from the provided details.

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

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

The input schema has 0% description coverage, so the description must compensate. It meaningfully defines every functional parameter: x_mm/y_mm as the center, length_mm as centre-to-centre, width_mm as slot width, angle_deg with 0=+X, and depth_mm as blind depth or through when omitted. Only the trivial name parameter is left to inference.

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 ('Cut') and resource ('straight slotted hole (obround) on the +Z face'), identifying exactly what the tool does. This distinguishes it from related sibling tools like cut_profile or add_hole without requiring the agent to inspect schemas.

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

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

The description implies when to use the tool: whenever a straight slotted hole on the +Z face is needed. However, it does not explicitly compare to alternatives such as cut_profile_on_face or add_hole, nor does it state when not to use it, leaving some selection guidance to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose one important trait beyond the name: deleting a component also deletes the mates that hold it. However, it says nothing about irreversibility, undo, or required permissions — meaningful gaps for a destructive mutation.

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

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

Front-loaded with the action and its side effect, then the parameter note, then the return summary. Every sentence earns its place; the parenthetical naming example is the only slightly verbose element.

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

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

No output schema exists, and the description compensates by naming what is returned (mates deleted, remaining components, mass properties). Combined with the parameter explanation and the cascade warning, this is nearly complete for a single-parameter tool; only precondition/permission details are missing.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains that 'component' is the name as it appears in list_components, including the exact naming convention ('Bracket-1', or bare 'Bracket' while unique). That is real meaning beyond a bare string parameter, though format nuances (case sensitivity, resolution of ambiguous names) remain 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?

States a specific verb and resource ('Remove a component from the current assembly') and immediately qualifies the scope with the cascading effect ('with the mates that hold it'). That cascading clause is what separates it from siblings like delete_mate and suppress_mate, so an agent can tell the tools apart 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?

The phrase 'from the current assembly' implies the precondition that an assembly is active, but there is no explicit when-to-use guidance and no routing to alternatives such as suppress_mate or delete_mate. Usage is only implied, not stated.

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

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

With no annotations present the description carries the full burden, and it does disclose the key side effect: the model is rebuilt as part of the deletion. It also names the return payload (deleted item, failing_features, mass properties). It stops short of saying whether deletion is irreversible or what happens when the equation name/index is not found.

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 identifier formats an agent needs before anything else. Minor awkwardness in the phrase 'the name it sets' and a slightly clipped second sentence, but nothing 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 a no-annotation, no-output-schema mutation tool, the description covers the essentials: input formats, the rebuild side effect, and the return contents. Remaining gaps are failure/error behavior and reversibility, which are secondary 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% and the single 'equation' property has no description, so the description must compensate — and it largely does, explaining the accepted name syntax with two concrete examples and the alternative list_equations index. It lacks detail on index base (0- or 1-based) or quoting rules.

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

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

States a specific verb and resource (delete an equation) and immediately defines the two accepted identifier forms — the name the equation sets, e.g. "L_thigh" or "D1@Boss", or its list_equations index. This separates it cleanly from set_equation/set_equations/list_equations without the agent needing to open any schema.

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

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

The description implicitly tells the agent how to supply the argument (name or list_equations index), which is genuine usage help. It does not, however, state when to prefer this over alternatives such as set_equation (modify) or delete_feature, nor any preconditions. Adequate but with clear gaps.

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

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

With no annotations present, the description carries the full burden and does so well: it discloses the refuse-on-dependents behavior and that dependent features are named, the with_children override, dry_run semantics (would_delete), the equation breakage and broken_equations reporting, the with_equations override with the caveat that global variables survive, and the implicit rebuild/remeasure side effect.

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

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

Front-loaded with the core action, then layered with conditions in a logical order. Dense and slightly run-on in the middle clause ("names them, and what is built on those"), but essentially every sentence conveys a distinct behavioral fact.

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 destructive, four-parameter tool with no annotations and no output schema, the description is nearly self-sufficient, even naming return keys (would_delete, broken_equations). Minor gaps remain around confirmation/permission expectations and the source from which the feature name must be obtained.

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 compensate for all four parameters, and it explains dry_run, with_children, and with_equations precisely in terms of observable effects. The required name parameter is only glossed as "a list_features name," leaving its format slightly implicit, but overall coverage is strong.

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

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

Specific verb ("Delete") plus resource ("a feature"), and it even resolves the argument identity by pointing to list_features names. It also frames the operation as "the way to undo a step," which distinguishes it from sibling mutators like suppress_feature and delete_equation.

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

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

Gives clear operational context (undo a step) and conditions under which behavior changes: refuses when children exist, with_children=True overrides that. However it never explicitly contrasts delete_feature against the obvious sibling alternative suppress_feature, so an agent must infer when deletion beats suppression.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a real effect ('Its components are free to move again') and the return value ('Returns the mates left'), which is more than baseline. It omits whether the deletion is permanent/undoable and any permission requirements, leaving meaningful gaps for a mutation tool.

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

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

Two short sentences, front-loaded with the action and scope, with the retrieval hint and behavioral note following. The parenthetical is slightly awkwardly embedded 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?

For a single-parameter delete tool with no output schema and no annotations, the description covers purpose, the effect on components, and the return value. It is reasonably self-sufficient, missing only permanence/permission detail.

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 schema only labels the field 'Name', so the description must compensate. It does so by clarifying the name identifies a mate and by pointing to list_components and add_mate's 'mate' output as sources for it, adding real meaning beyond 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 (delete a mate) and scopes it to the current assembly, which cleanly separates it from siblings like delete_component and suppress_mate. It does not explicitly name suppress_mate as the non-destructive alternative, so it falls just short of full sibling differentiation.

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

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

The parenthetical '(list_components, or add_mate's "mate")' implies where the required name comes from, which is useful implied usage guidance. However, it never states when to use this versus suppress_mate or what preconditions apply, so usage is only inferred.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that export is silent (no prompts), verifies the file exists on disk, reports its size, describes the assembly-to-STL naming/coordinate behavior, and explains the tessellation override logic. It omits overwrite/permission behavior and failure modes, keeping it short of a 5.

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

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

Content is front-loaded (format, then silent/verification behavior, then format-specific tessellation rules), and each sentence carries real information. It is on the longer side with a few parenthetical asides, but nothing is filler.

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

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

For a no-output-schema, no-annotation mutation tool, it covers the return signal (`files` lists what was written, size reported) and the tricky assembly/coordinate cases. The remaining gap is the unexplained file_format parameter and lack of error/overwrite semantics.

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 compensate, and it explains quality, deviation_mm, angle_deg, and per_component well. However, it never clarifies the file_format parameter (it instead says format comes 'from extension') or the path parameter, leaving two of six params semantically unresolved.

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 (export), the exact resource (current part or assembly), and enumerates the supported interchange formats (STEP/STL/IGES/Parasolid/3MF), so the purpose is unambiguous. It does not explicitly contrast itself with save_part/save_assembly, but the format list implicitly separates it from native-save siblings.

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

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

Usage context is implied (producing interchange meshes/CAD for external tools) rather than stated. There is no explicit 'use this vs. that' routing and no mention of prerequisites like an active/fully-rebuilt document, which matters given it targets 'the current part or assembly'.

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

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

With no annotations the description carries the full burden, and it does disclose real behavior: the result is merged with the body, the sketch keeps its dimensions/relations (a non-destructive claim about authored geometry), the return is mass properties, and it hints at failure semantics ('the refusal names a point ahead'). It omits whether the operation is purely additive and what preconditions (active part, valid sketch) apply.

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, but the body is a run-on of nested parentheticals and asides ('e.g. one a person drew', 'so the person's design stays in charge') that make the mode logic harder to scan than it needs to be. Information density is high, yet the structure could be tightened without losing content.

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 annotations, no output schema, and five undocumented parameters, the description supplies a lot: modes, direction, return value, and sketch preservation. It remains a bit short on preconditions and on the 'name' argument for a tool whose siblings imply richer feature-graph behavior.

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

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

Schema coverage is 0%, so the description must compensate, and it does well for three of five parameters: depth_mm is 'along the sketch's normal', reverse=True goes the other way, and up_to accepts 'next' or a '@x,y,z' point with distinct behaviors. The 'name' parameter (feature naming, default 'Extrude') is never explained, leaving one gap.

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

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

The first sentence gives a specific verb+resource ('Extrude an existing sketch of the current part by name'), and the qualifier 'existing sketch' implicitly distinguishes it from siblings like add_extruded_profile that create new geometry. It does not name any sibling outright, so the differentiation is inferred rather than stated.

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

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

It gives clear selection logic among modes: depth_mm along the normal, or up_to='next', or up_to='@x,y,z' when 'next' fails, plus the prerequisite 'read_sketch shows it first'. It never says when to prefer this tool over cut_sketch or add_extruded_profile, so the routing guidance is incomplete.

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

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

No annotations are provided, so the description carries the full burden. It clearly discloses the return content (min/max/size in mm), and the verb 'Get' with zero parameters strongly signals a non-mutating query. It does not mention prerequisites like having an assembly open, but that is a minor omission for such a simple getter.

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

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

The description is a single, front-loaded sentence with no filler. Every element—verb, resource, scope, output, and units—is meaningful, and the most important scoping detail ('whole assembly') appears early.

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 zero parameters, no annotations, and no output schema, the description covers everything needed to invoke the tool correctly and understand its result. It states what is returned and in what units, making it complete for an operation of this simplicity.