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

No annotations exist, so the description carries the full load it can: it discloses that this is a focus/activation action on documents that are already open, including never-saved ones, which is genuinely useful behavioral context. It does not say whether unsaved edits survive, whether the operation can fail on a bad title, or how ambiguous duplicate titles are resolved, leaving real gaps for a zero-annotation 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 with the core action front-loaded and the disambiguation hint immediately after. The phrase 'also a new one that was never saved' is grammatically awkward and costs a re-read, but nothing is padded.

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

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

For a one-parameter tool with no output schema, the description covers the action, the parameter source, and the surrounding workflow with open/close/list_documents. The remaining omissions (failure on unknown title, duplicate titles) are minor for what is effectively a window-focus operation.

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

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

Schema coverage is 0% and the lone 'title' property has no description, so the description must compensate. It does, by stating the lookup is 'by its title' and by directing the agent to list_documents for valid titles, which tells the agent the expected format and source of the 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 and resource ('Make an open document current again by its title') and implicitly distinguishes itself from open_document/close_document by naming them as different operations. The clause 'also a new one that was never saved' is a bit muddled but signals the tool targets already-open documents rather than opening new ones.

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 to use it 'after open_document / close_document on another document', giving a concrete triggering condition, and points to list_documents as the source of valid titles. It stops short of stating what happens when the document is already current or when no match exists, so it is clear context rather than full when/when-not guidance.

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

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

No annotations are provided, so the description carries the full behavioral burden. It explains axis definition syntax and that the axis can be referenced by name in add_circular_pattern, but it does not state mutation/persistence behavior, validation rules when neither or both definition forms are supplied, or what happens on failure.

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

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

The definition is compact and front-loads the two construction methods, with no wasted sentences. The opening phrase "A reference axis anywhere" is slightly indirect, but the parameter examples and downstream usage note are efficiently stated.

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

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

For a 3-parameter CAD modeling tool with no annotations, no output schema, and 0% schema description coverage, the description covers the two main geometric inputs but omits the name parameter, optionality behavior, and constraints when both through and planes are provided. It is adequate to attempt a call but leaves meaningful gaps.

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

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

Schema description coverage is 0%, so the description must compensate; it does this well for through (point and direction in model mm with an example) and planes (two named planes with an example). It leaves the name parameter unexplained and does not clarify mutual exclusivity or defaults for through/planes.

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

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

The description clearly identifies the resource as a reference axis and gives the two defining constructions. It lacks an explicit verb such as "creates" and does not differentiate this from the sibling add_plane tool, but the axis-specific purpose is clear.

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

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

It implies usage by showing the through-point/direction form and the intersecting-planes form, and notes that patterns can rotate about the axis by name. It does not explicitly say when to use this versus add_plane or when one construction form is preferable.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the result includes mass properties and `dimensions`, and notes a special PCB-standoff blind-hole behavior, but it omits mutation effects, active-document requirements, permissions, and failure/constraint behavior.

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

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

The description is short and front-loaded: the core action, dimensions, and face behavior come first, followed by a useful PCB-standoff note and return-value note. There is essentially no wasted text.

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

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

This is a 7-parameter CAD mutation tool with no annotations, no output schema, and 0% schema description coverage. The description mentions only part of the parameter set and does not cover constraints, document state, or all behavioral expectations, so it is not complete enough for the complexity.

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 height_mm, x/y/z centering, and face selection by analogy to add_hole, but it does not document diameter_mm or the optional name parameter, and gives no constraints or format details for face.

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: grow a round boss/standoff/peg from a planar face at explicit coordinates. It clearly distinguishes the operation from siblings such as add_hole, add_cylinder, or add_disc by naming the resulting feature.

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 PCB-standoff use case and says face selection follows add_hole with face=, which implies when the tool is appropriate. However, it never explicitly says when to use this instead of add_cylinder, add_extruded_profile, or add_hole, nor does it state 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 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?

With no annotations, the description carries full behavioral burden. It discloses defaults (feature_name defaults to last feature, angle_deg default 360), axis resolution logic, and angle_spread semantics, which is meaningful. However it says nothing about return values, failure modes (e.g. missing feature/axis), or side effects on the feature tree.

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 in the first sentence, then parameter detail and a workflow example. Dense but nearly every clause carries information; minor density in the axis sentence 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 6-param mutation tool with no annotations and no output schema, parameter semantics are well covered, but the description omits what is returned and error/precondition behavior, leaving an agent guessing about outcomes.

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: it explains axis (nearest cylindrical face to center, 'y', or a named reference axis), the role of center_x_mm/center_y_mm, feature_name defaulting, and angle_deg<360 spread behavior, with count defined in the opening sentence.

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: 'Repeat a feature count times evenly around 360° about an axis.' It is clearly distinguishable from add_linear_pattern and add_mirror by the circular/angular scope, though it doesn't explicitly name those siblings.

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

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

Gives a concrete usage recipe (bolt circle: drill a centre hole plus one bolt hole, then pattern the bolt hole) and explains axis selection choices. It lacks explicit when-not-to-use guidance or a direct contrast with add_linear_pattern, so it stops short of 5.

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

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

No annotations exist, so the description carries the full behavioral burden. It does valuable work by disclosing that mass properties are returned and spelling out the volume formula, and by hinting that it operates on the active document. It does not say whether the result is a new body or a merged feature, what happens with invalid diameter combinations, or anything about units failure modes beyond the _mm suffixes.

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 lines, front-loaded with the verb and construction method, then the edge-case rule, then the return contract. The formula earns its place because it tells the agent what to expect back without an output 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 simple primitive-creation tool with no annotations and no output schema, the description covers what is built, the degenerate case, and the return payload well enough to call it correctly. The only real gap is the unexplained 'name' parameter and the absence of any statement about whether the solid is added as a new body in the active document.

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

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

Schema description coverage is 0%, so the description must compensate. It partially does: the 'top_diameter_mm = 0' rule gives real semantics for that parameter, and the volume formula's rb/rt/h implicitly map to bottom_diameter_mm, top_diameter_mm, and height_mm. The fourth parameter, name (default 'Revolve'), is never explained, so coverage remains incomplete for a 4-parameter tool.

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

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

States a specific verb and resource ('Create a cone/frustum') plus the exact construction method ('revolving a trapezoidal profile 360°'), which cleanly separates it from siblings like add_cylinder, add_disc, and add_revolved_profile. The clarifying rule 'top_diameter_mm = 0 gives a full cone' removes the only ambiguity about what shape results.

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

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

'Use new_document first' is a genuine prerequisite that helps sequencing, but there is no guidance on when to pick this over add_cylinder, add_disc, or the more general add_revolved_profile, and no exclusion for cases where a frustum is degenerate (e.g. top > bottom).

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 behavioral burden: it discloses a prerequisite (new_document) and claims the return includes mass properties. It omits what document/body the feature lands in, whether the axis/orientation is fixed, and whether it errors without an active document, so the disclosure is partial.

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?

Very short and front-loaded, with the core action in the first sentence and the prerequisite last. The line 'The first revolve-based primitive' is trivia that earns little place, but the padding is minor.

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

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

For a mutation tool with zero annotations, no output schema, and 0% parameter coverage, the description is thin: no units semantics beyond suffixes, no document-state requirement details, no indication of what the volume/mass claim implies versus the separate get_mass_properties 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 explain all three parameters. It implies height via 'h' and radius via 'r', but the required input is diameter_mm, and the description never reconciles diameter with the radius in the volume formula; the 'name' parameter (default 'Revolve') is entirely unexplained.

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

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

States a specific verb and resource plus the construction method ('Create a cylinder by revolving a profile 360° about an axis'), which helps distinguish it from add_disc or add_cone. The sibling set is large but the geometry description is enough to distinguish it from add_extruded_profile or add_loft.

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 explicit prerequisite ('Use new_document first'), which is genuinely useful. However, it never says when to pick this over add_disc/add_cone or the generic add_revolved_profile, so the agent must infer alternatives from names.

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 disclose useful behavior: default side placement ('nearer the geometry'), default offset row progression (10, 18, 26 ...), and an explicit return payload of ids, values, boxes, and overlap warnings. It stops short of stating that this is a persistent mutation, whether it is undoable, or what error conditions exist.

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

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

Dense but front-loaded: the core purpose is in the first sentence, followed by parameter semantics in a compact order. The telegraphic phrasing ('its centre; alone its diameter') occasionally reads like notes rather than prose, but no sentence is wasted.

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

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

For a 7-parameter mutation tool with zero schema description coverage and no annotations, the description covers most of what an agent needs: accepted reference syntaxes, style/direction/side vocabularies, placement defaults, and return contents. The unexplained required 'view' parameter and absent error/prerequisite behavior leave a real gap.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: ref formats ('edge:-x', 'hole:CBore1', 'feature:CornerFillet', model point [x, y, z]), to, style, direction, side, and offset_mm all get concrete value semantics and defaults. The required 'view' parameter is never explained — no format, no statement of what a view identifier is.

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 and resource: adding a dimension in a view between references, or a size of one. The scope (single span vs. series) is enumerated. It does not explicitly distinguish itself from siblings like set_dimension, list_dimensions, or import_dimensions, so an agent must infer the difference from the verb alone.

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

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

The description gives strong in-tool guidance for choosing a style ('single' with ref/to vs. 'baseline'/'chain'/'ordinate' with to=[ref, ref, ...] measured from ref) and sensible defaults for side and offset. However it never says when to use this tool rather than set_dimension or import_dimensions, nor any prerequisite such as requiring an existing drawing view.

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

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

With no annotations, the description carries the full burden and discloses key behavior: the disc is centered by default at the origin, off-origin x/y are treated as dimensions, flat faces are +Z/-Z, and the tool returns mass properties. It does not detail failure modes or document-modification side effects, but it covers the essential behavioral traits.

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 geometry definition, followed by composition guidance and a prerequisite. Every sentence adds useful information with no repetition or filler.

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

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

The tool has 5 parameters, no output schema, and no annotations. The description covers creation, orientation, coordinate semantics, composition, prerequisite document state, and return values ('mass properties'), which is nearly complete for this primitive, though parameter-level details for all five parameters are not fully spelled out.

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 x_mm/y_mm centering semantics and implies diameter/thickness through 'circle extruded along +Z', but it does not explicitly describe diameter_mm, thickness_mm, or the name parameter beyond what their titles suggest.

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

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

The description states a specific verb and resource: 'Create a disc/puck/flange: a circle extruded along +Z'. It also specifies orientation and centering, so an agent can distinguish this primitive from generic extrusion or other add_* 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?

It gives clear context: 'Use new_document first' and notes that add_hole and add_circular_pattern compose with it for round-flange bolt circles. It does not explicitly say when to prefer this over add_cylinder or add_extruded_profile, but the intended use case is clear.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses auto-closing, rotation convention, spline smoothing, reverse extrusion, argument/variant rejection, and merge=False producing a separate body. It also explains the return value (mass properties) and even the volume formula, which is unusually transparent 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?

The description is front-loaded with the core operation, then organized into bulleted variants and parameter notes. It is long, but the length is largely justified by 12 undocumented parameters; some dense parentheticals and the corner-volume formula could be trimmed without losing much.

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 12-parameter tool with no annotations, no output schema, and 0% schema description coverage, this is nearly complete: it covers geometry, variant behavior, merge behavior, and return values. The remaining gap is the undocumented 'name' parameter and the description's reliance on the caller knowing add_box/add_hole/add_plane conventions.

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: it explains points_mm formats for all three modes, depth_mm direction, rotate_deg/about_mm, spline, face and plane semantics, reverse, corner_radii_mm formatting and dimension naming, and draft_deg sign behavior. Only the 'name' parameter is left unexplained, which is a minor gap against 12 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?

States a specific verb and resource: 'Extrude a closed polygon into a solid; it is auto-closed.' It also distinguishes the three operating modes (default plane, face, named plane) and names related siblings such as add_box and add_plane for orientation. An agent can tell this is profile extrusion, not box/disc/cylinder creation.

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 when-to-use context for each variant: default for first-plane profiles, face='+z' for bosses/pads/ledges/mounting blocks, plane='Plane1' for plane-defined profiles. It also points to list_bodies/combine_bodies when merge=False, but does not explicitly say when to prefer siblings like add_boss_on_face or extrude_sketch over this tool.

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

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

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 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 load well: it discloses the return payloads (`dimensions`, `hole`, mass properties) and the non-obvious side effect that thread='modeled' produces a real printable thread rather than a cosmetic one. It omits that the operation mutates/removes material from the active body and any preconditions (e.g. requires an existing part), which for a cut feature is a meaningful gap.

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

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

Front-loaded with the verb, then organized as scannable bullets each keyed to an argument pattern. It is long, but justified for a 13-parameter, three-mode tool; the density of the first bullet (coordinate aside plus hole spec) costs a little readability.

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

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

For a 13-param tool with zero schema coverage and no output schema, this covers the modes, geometry semantics and return shapes that an agent actually needs. Missing pieces are the destructive/mutating nature of the cut, the unexplained `name` parameter, and any failure conditions — minor but real for a modeling operation.

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

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

Schema description coverage is 0% and 13 parameters exist, so the description must compensate — and it does: it explains 12 of 13 parameters with real semantics, including the shared coordinate system (40x20 profile centre = x=20,y=10), face string values ('+z', '-x'), depth semantics (through vs blind), the fit/thread/iso enumerations and their effects. 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?

Opens with a specific verb+resource ("Cut a round hole") and immediately partitions the tool into three distinct operating modes. It also anchors the coordinate system to a named sibling (add_box), so an agent can tell exactly what geometry this produces versus cut_slot, cut_profile or cut_offset_pocket.

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?

Strong intra-tool routing: each bullet names the argument combination that selects it (diameter+xy = through hole, face+z_mm = face-anchored, cbore_* = counterbore, iso= = Hole Wizard), plus an explicit preference rule ("Prefer iso= for standard fasteners"). It never states when to choose this over sibling cut tools (cut_slot, cut_profile), so it stops short of full when/when-not coverage.

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

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

With no annotations 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 provided, the description carries the behavioral burden well: it explains cut semantics, profile ordering/twist risk, blend behavior, and that mass properties are returned. It still omits permission requirements, failure modes, and document-modification details, but adds substantial context beyond the schema.

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

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

The description is front-loaded with the core operation and organized into two clear input modes. It is dense and mostly earns its length, though the multi-line format could be slightly tighter for a tool definition.

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 loft feature with no annotations and no output schema, the description gives enough detail on input modes, constraints, and return behavior. It remains incomplete only around the missing name parameter and unstated failure conditions.

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 document all five parameters. It explains sketches, cut, profiles_mm, and heights_mm formats and constraints in detail, but never mentions the name parameter, leaving one 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 CAD operation: lofting/blending 2+ closed profiles, with two input modes. It is clear what the tool creates, but it does not explicitly contrast itself with siblings like add_swept_profile or 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?

The description explains the two ways to supply profiles and gives constraints such as ordering and height rules. However, it does not explicitly say when to choose loft over alternative sibling tools or when not to use it.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that results are measured after rebuild, a failing mate is removed and components restored, flip's mirror/opposite behavior, and stop_on_error semantics including that prior mates persist. It also describes the return payload (per-mate result, counts, mate count), which is critical given there is no output schema.

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

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

The purpose is front-loaded and the body is dense with useful detail rather than filler. It is long, but that length is largely justified by the ten undocumented parameters and the need to specify face addressing, mate types, and batch behavior.

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

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

For a complex, zero-annotation, no-output-schema tool, the description covers invocation, face syntax, mate-type semantics, batch error behavior, and return shape. An agent has enough to call it correctly and interpret results without guessing.

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 fully, and it does: it explains comp_a/comp_b naming conventions, face_a/face_b addressing (direction, index, '#5', '@x,y,z', cavity suffix), mate_type values, distance_mm, angle_deg range and wraparound semantics, flip, mates array shape, and stop_on_error. Every one of the ten parameters is given meaning beyond its bare name.

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

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

States a specific verb and resource ('Mate a face of one component to a face of another') plus the batch variant ('add several mates in one call'), which cleanly separates it from siblings like delete_mate, suppress_mate, and set_dimension. An agent can identify the operation without opening the schema.

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

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

Explains the mate types and when each applies (planar vs cylindrical, concentric leaving rotation free), and routes follow-up work to set_dimension and check_motion. It does not explicitly say when to prefer a single call over a batch, but the context is clear enough for 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?

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?

No annotations at all, so the description carries the full load, yet it only discloses the default placement ('by default above the title block'). For a mutation tool it says nothing about required document state, whether the note joins an annotation list, or how it can later be edited or removed.

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?

Very short with no filler, but the telegraphic style ('Lines: \'\n\'.') borders on cryptic and the string reads as a fragment rather than a front-loaded purpose statement. Space saved is not redeployed on the undocumented height parameter.

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

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

For a three-parameter mutation with no annotations and no output schema, the definition leaves important gaps: sheet context requirements, the meaning of height_mm, and what the call returns. It is adequate only for an agent that already knows the drawing model.

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 well for 'at' (top-left corner, sheet millimetres, default above title block) and for 'text' (newline handling), but 'height_mm' is never mentioned despite defaulting to 3.5 and plausibly meaning text height.

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

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

Names the resource ('a note on the sheet') and implies creation via the tool name, and the positioning detail makes clear this places annotation text on a drawing sheet rather than a model face. It does not explicitly contrast with near neighbors like add_text_on_face, add_symbol, or add_table, so differentiation relies on inference from 'sheet'.

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

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

No statement of when to use this versus add_text_on_face, add_symbol, add_table, or edit_annotation, and no prerequisites (does a drawing need to exist or be active?). The agent must infer usage entirely from the resource noun.

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

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

With no annotations provided, the description carries the full burden and does well: it discloses operation order ('turn first, then offset'), return values, and the plane coordinate frame. It does not cover failure conditions or default behavior when parameters are omitted, which keeps it from a 5.

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

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

The description is front-loaded with purpose and then proceeds through construction modes efficiently. It is dense and somewhat run-on, but nearly every clause contributes geometric meaning, so it remains useful 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 geometry tool with no annotations and no output schema, the description provides substantial completeness: construction modes, axis conventions, and return coordinate frame. It still omits the name parameter's purpose and any error/omission 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. It explains base, offset_mm, angle_deg, about axis mappings, through, and normal semantics in useful detail, but the name parameter is left unexplained and defaults are only partially implied.

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: 'Make a reference plane to sketch on.' It immediately clarifies the tool's role in creating construction geometry, which distinguishes it from sketch/profile creation siblings like add_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?

The description explains the available construction modes in detail, but it does not explicitly say when to choose this tool over siblings such as add_axis or add_sketch, nor does it state exclusions. Usage is implied by the mode descriptions rather than routed against 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?

With no annotations the description carries the full burden, and it delivers: auto-closure, default 360° sweep, the geometric consequence of touching vs. offset profiles (solid vs. ring), a hard validity constraint (profile may not cross the axis), a scoping caveat on corner_radii_mm, the fact it returns mass properties, and the new_document prerequisite. It omits body/merge behaviour and failure modes, so not a 5.

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

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

Front-loaded with the operation, then immediately with the parametric mode split, then constraints and return value. Dense but every sentence adds information an agent could not get from the schema; 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 5-parameter geometry-creation call with zero annotations and no output schema, the description supplies coordinate conventions, defaults, validity constraints, the return value (mass properties) and the required predecessor tool. Remaining gaps are secondary: whether the result is a new body or merged, and what happens on invalid input.

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 explains 4 of 5 parameters in substance: profile_mm's coordinate convention changes with axis_mm (r/z vs x/y), axis_mm's two-point line form and its freedom in position and angle, angle_deg's default, and corner_radii_mm's exclusion on axis points. Only `name` is undocumented, which keeps it off a 5.

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

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

States a specific verb and resource ("Revolve a closed profile on the Front plane about an axis") plus the resulting geometry class, which distinguishes it from add_extruded_profile, add_swept_profile and the primitive add_cylinder/add_disc siblings. An agent knows exactly which feature this creates 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 a hard prerequisite ("Use new_document first") and lays out the two mutually exclusive operating modes (no axis_mm = polar r/z profile about the Y axis; axis_mm = free [x,y] points with an arbitrary axis line), which is effectively when-to-use guidance for each branch. It stops short of naming an alternative tool and saying when not to use this one, so no 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 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 substantial work: it discloses the automatic dimensioning scheme (tangent relations, x<i>/y<i>, r<k>), the closing rule ('End on start_mm to close the outline'), and the fixed=True behavior of substituting Fix relations for dimensions. It stops short of stating failure modes, undo semantics, or that this is a mutating document operation.

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

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

The summary sentence is front-loaded and every subsequent clause carries specification detail rather than filler. Density is justified by the complexity, though the plain-prose paragraph with mid-sentence line breaks is harder to scan than a structured segment list would 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?

For a 5-parameter, no-output-schema, no-annotation tool this is close to complete: it even previews return-value fields (origin_mm, x_axis, y_axis, points_mm) so the agent knows what comes back. The remaining gap is that the rest of the returned sketch object and error conditions are left unstated.

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

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

Schema coverage is 0%, so the description must compensate and largely does: plane enumerates the accepted values and coordinate mapping per plane, start_mm defines the origin convention, segments spells out each verb's object shape (line, arc with through/tangent, spline), and fixed explains the geometry mode. Only the optional trivial 'name' parameter is left implicit.

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

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

The opening sentence gives a specific verb and resource ('Draw a sketch of lines, arcs and splines on a plane') and states the downstream intent ('to extrude or cut'). It is immediately distinguishable from sibling profile/primitive creators like add_extruded_profile or add_disc, which do not produce an editable 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?

It clearly routes the agent: 'Then extrude_sketch / cut_sketch the returned sketch', establishing the follow-up step. It also distinguishes the fixed=True mode as a variant for frozen geometry. What it does not do is state when to prefer this over a non-sketch primitive (add_box, add_disc) or a script-based path.

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 load. It discloses that the profile is auto-generated perpendicular to the path, that bend_radius_mm is required when the path turns, what smooth=True does, and that it returns mass properties calculated as pi r^2 x path_length_mm. It does not cover error conditions or whether a new body/feature is created, keeping it below the top score.

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 front-loads the verb and resource in the first sentence, then spends each subsequent sentence on a distinct parameter or behavioral fact. There is no redundant restatement of the name or schema, and the prerequisite is placed at the end as a natural call-order note.

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 annotation coverage, no output schema, and five undocumented-in-schema parameters, the description supplies enough to call the tool correctly: path format, required inputs, bend behavior, profile orientation, return values, and a document prerequisite. It is somewhat silent on error conditions and whether it creates a new body or feature, which are the remaining gaps.

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

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

Schema description coverage is 0%, so the description must compensate, and it does so for the important parameters: path_mm format [[x,y]] in mm as a centreline on the Front plane, diameter_mm as outer Ø, bend_radius_mm behavior including the 2-point straight-path exception, and smooth as a spline alternative. Only 'name' is left undocumented, which is a minor defaulted parameter, so a 4 rather than 5 is appropriate.

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

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

The description gives a specific verb and resource — 'Sweep a circular profile (pipe/tube/rod) along a 2D path on the Front plane' — which an agent can readily distinguish from generic sweep or extrusion tools. It stops short of explicitly naming or contrasting the closest sibling (add_swept_profile), so it misses the top mark for 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 only explicit usage guidance is the prerequisite 'Use new_document first.' The description implies when to use it by describing the pipe geometry, but it never states when to prefer this over add_swept_profile, add_cylinder, or add_extruded_profile, nor does it give exclusions or conditions. That leaves selection guidance implied 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, the description carries the full burden and does most of it: coordinate-frame mapping (u → world -Z, v → world +Y; path on Front plane), profile centering, corner-rounding behavior for both path and profile, and a volume formula. It stops short of saying whether the result is a new solid body, whether it merges with existing bodies, or what failure modes exist if the path precondition is violated.

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

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

Front-loaded with the core action and organized so each clause covers one parameter or rule, with no filler sentences. It is dense and arrow-notation-heavy, and the volume formula is arguably optional, but every sentence otherwise 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?

It states the return ('Returns mass properties'), which is necessary since no output schema exists, and covers all the geometric call prerequisites. What remains missing is whether the sweep produces a standalone body and how it interacts with existing geometry — meaningful for a modeling tool with zero annotation coverage.

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: profile_mm and path_mm get format, units, construction plane and orientation rules, bend_radius_mm is tied to path corner rounding, and corner_radii_mm is tied to profile corner rounding with a cross-reference to add_extruded_profile. Only 'name' is left undocumented, which is a harmless cosmetic default.

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

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

Opens with a precise verb+resource: sweep a closed profile along a 2D path. The parenthetical '(cross-section)' and the clause 'For non-round extrusions along a path' implicitly separate it from add_swept_pipe (round) and add_extruded_profile (straight), so an agent can pick it out of the sibling list 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?

Gives a concrete use case (rails, gaskets, trim, channels) plus a hard prerequisite ('Use new_document first') and a mandatory path constraint ('MUST start at the origin heading +X'). It never explicitly names a sibling to avoid, so the routing is implied by 'non-round' 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?

No annotations are provided, so the description carries the full behavioral burden. It adds useful behavior details such as hole_callout being linked to the model, count=True producing '4X ...' labels, and default placement off the view clear of text, but it does not describe side effects, required document state, failure modes, or what the tool returns.

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

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

The description is front-loaded with the core concept and then uses a compact bullet structure to explain the type-specific fields. It is appropriately sized for a 13-parameter annotation tool, though some density could be reduced by defining 'view' explicitly rather than leaving it implicit.

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, 13-parameter mutation tool with no annotations, no schema descriptions, and no output schema, the description is fairly complete on symbol-type semantics and placement. However, it omits the required view parameter's meaning and lacks general mutation/return behavior, leaving meaningful context 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?

With 0% schema description coverage, the description compensates strongly by explaining most of the 13 parameters: type-specific ref formats, count, label, datums, symbol, process, diameter, roughness, tolerance, material_condition, and at in sheet millimeters. The notable gap is the required 'view' parameter, which is never directly defined.

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

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

The description clearly defines the resource as a drawing symbol annotation placed on a view edge with its leader attached mid-edge, and it enumerates the supported symbol types. It does not explicitly contrast itself with sibling annotation tools like add_note or add_dimension, but a competent agent can still distinguish it as the tool for geometric/drawing symbols.

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 lists symbol types but gives no explicit when-to-use guidance, no when-not-to-use guidance, and no alternatives. The only implicit routing hint is 'ref as in add_dimension,' which is not sufficient for choosing this tool over add_dimension, add_note, or edit_annotation.

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 discloses title-row merging and default free-room placement, but omits whether it mutates the active document/sheet, what happens on collision, permissions, return values, and 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?

The description is dense but appropriately sized and front-loads the rows mode before gear mode. However, it reads as one long run-on sentence with inline nested field lists, and it does not lead with a clear action statement.

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

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

For a six-parameter mutation tool with no annotations, no output schema, and zero schema descriptions, the description leaves out two top-level parameters and operational context such as which sheet/document is targeted. The gear detail is useful but does not make the definition complete enough for reliable 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 document six parameters. It covers rows, title, at, and many gear subfields with defaults, but completely omits text_height_mm and column_widths_mm, leaving a significant 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 names the resource ('a table on the sheet') and separates two modes (rows vs gear), but it never states an explicit verb such as 'adds' or 'creates'. It also does not distinguish itself from siblings like add_note or add_symbol; the tool name carries most of the action meaning.

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

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

It explains gear table variants ('spur' or 'bevel'), but gives no guidance on when to use this tool versus alternatives such as add_note, add_symbol, or drawing annotation tools. No prerequisites, exclusions, or selection criteria are provided.

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

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

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 full burden. It discloses useful behavior such as automatic placement with room for dimensions, collision avoidance via gap_mm, label naming for section/detail views, and alias handling; however, it does not state that it mutates the active drawing, what permissions/context are required, or what is returned.

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

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

The bullet structure is front-loaded with the core action and kind-specific details. Given 16 parameters, the density is justified, though a few phrases (e.g., orientation '*Name') are cryptic rather than concise.

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?

Covers the complex geometry and naming behavior well, but for a 16-parameter mutation tool with no annotations and no output schema, it omits prerequisites such as an active drawing context and leaves the 'part' parameter undocumented.

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

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

Schema description coverage is 0% across 16 parameters, so the description must compensate. It explains most parameters in context: kind, orientation, at, beside/side, parent, through/normal, label, flip, center, radius_mm, scale, gap_mm, and name-as-alias; only 'part' 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 the specific verb+resource ("Add a view") and enumerates the four view kinds with their geometric behavior. It is clearly distinct from list_views/edit_view, though it does not explicitly name those siblings as alternatives.

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

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

Explains when each kind is appropriate (model, projected, section, detail) and how placement works, but gives no broader when/when-not guidance, no prerequisite that a drawing/document must exist, and no explicit alternative for modifying an existing view.

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

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

No annotations, so the description carries the full burden. It does well on the mechanics: largest standard scale that fits unless scale is given, and the effect of arrange_dimensions. It never says the operation overwrites existing view positions or that it needs an open drawing, which matters for a mutating tool.

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

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

Front-loaded with the action and dense with meaning; nearly every clause carries layout policy. The opening sentence runs long and packs both placement and scaling into one breath, but there is no filler.

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

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

For a 3-parameter mutating tool with no annotations, no output schema and no schema descriptions, the description conveys the layout algorithm but leaves the 'main' parameter and the required document state unexplained. That is a real gap against the complexity.

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 scale (overrides the auto-chosen largest standard scale) and arrange_dimensions (SolidWorks spaces each view's dimensions evenly), covering two of three parameters, but the 'main' parameter is never mentioned at all — an agent cannot tell whether it takes a view name, index or handle.

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

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

Specific verb plus resource: it re-lays out the views of a drawing, with the placement policy spelled out (main top-left, projections beside it, remainder in leftover room). An agent can tell this apart from add_view, edit_view and list_views without opening a schema. It just never names a sibling to distinguish against explicitly.

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

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

The word 'again' hints that this is a re-layout to run after views exist, but there is no statement of when to prefer this over edit_view or manual placement, and no prerequisites such as an active/open drawing. Usage is implied 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, the description carries the behavioral burden. It usefully says the drawing is 'Saved to path when given' and that it returns what was made plus problems found by check_drawing, but it does not disclose overwrite behavior, side effects, or permission requirements for a mutating build operation.

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

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

The purpose is front-loaded, followed by the necessary spec shape and then the save/return behavior. The large spec block is dense but justified for a complex nested parameter, and there is little wasted prose.

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

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

The description gives enough to construct a rough spec and understand that the result includes check_drawing problems, which is important because no output schema exists. However, for a complex mutating tool with no annotations and low schema coverage, it omits important operational details such as overwrite behavior, validation errors, and routing relative to sibling drawing tools.

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

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

Schema description coverage is 0%, and the input schema only defines spec as a generic object, so the description must compensate. The inline spec example is quite detailed, covering part, sheet, scale, views, import, dims, callouts, symbols, notes, tables, props, and layout, which substantially clarifies the nested object; it is still an example rather than exhaustive documentation.

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

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

The description states a specific verb and resource: build a drawing from a spec, then edit the spec and rebuild. It clearly frames the tool as a spec-driven drawing builder rather than incremental feature creation, though it does not explicitly distinguish itself from the similar sibling make_drawing.

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

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

The description implies usage through phrases like 'from scratch' and 'edit the spec and rebuild to fine-tune', giving a reasonable workflow context. However, it does not state when to prefer this over make_drawing, add_view, or edit_view, nor does it give 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 at all, the description carries the full burden; it does add real substance by enumerating the specific rules applied, including a concrete threshold ('text under 2.5 mm') and the feature types that must be dimensioned. It does not state that the operation is read-only, whether it needs an open drawing document, how findings are reported (list, severity, coordinates), or whether it modifies anything.

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 intent sentence is front-loaded and the checks are packed into one compact enumeration with no filler. It is somewhat list-heavy and would read better with an explicit leading verb, but every clause names a distinct check and 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 zero-parameter tool with no output schema and no annotations, the description covers what is inspected but not what comes back — an issue list, a pass/fail verdict, per-item locations — nor the document precondition. The omission of return shape is the main gap, since no output schema exists to fill it.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the schema is an empty object at 100% coverage. Baseline 4 applies — no parameter gaps exist to compensate for.

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 makes clear it reports drawing-sheet defects, and the enumerated categories (views outside the frame, overlapping texts, text under 2.5 mm, duplicate dimensions, undimensioned features) pin the resource down to a drawing sheet rather than a 3D model. It never uses a verb like 'checks' or 'returns', and it doesn't explicitly distinguish itself from the check_* siblings (check_printability, check_interference, check_motion) — the drawing context does that implicitly.

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?

'to fix before sending the drawing out' implies a pre-export QA moment, which is a usable usage cue. However, there is no explicit when-to-use statement, no prerequisite (e.g. an active drawing document must exist), and no reference to alternatives such as render_drawing or check_printability, so the agent must infer the routing.

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

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

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 provided, the description carries the full behavioral burden and does so thoroughly: it discloses that unsaved changes are discarded unless save=True, that save=True overwrites the document's own file, that the result reports discarded_changes, and that certain loaded parts are refused. This is strong transparency for a destructive operation.

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

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

The purpose and title-based behavior are front-loaded, followed by save semantics, refusal behavior, and fallback behavior. Every sentence adds necessary operational detail, and there is no redundant filler despite the number of edge cases covered.

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

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

For a two-parameter tool with no annotations or output schema, the description is complete enough to call correctly. It covers the optional title behavior, save behavior, refusal cases, fallback behavior, and even the result indicator for discarded changes.

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 explain both parameters, and it does. It explains that title selects a specific open document and that omitting title targets the current part/assembly; it also explains that save=True saves over the original file first, while false means unsaved changes are lost.

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 (close) and resource (one open document), and scopes it to parts, assemblies, or drawings. It also points to list_documents for obtaining titles, making the operation distinguishable from sibling tools such as save_document and open_document.

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

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

It clearly states the two primary usage modes: close by title, or close the current part/assembly when title is omitted. It also states exclusions and fallback conditions, including that assembly-loaded parts are refused and that SolidWorks' active document is closed only when it has no unsaved changes. It does not explicitly compare against save_document as an alternative when saving is the goal, which keeps this from a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It 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 burden and does disclose key behaviors: polygon auto-closure, through-all when depth is omitted, symmetric cutting about a plane, corner rounding, and that mass properties are returned. It omits whether the cut is reversible/feature-tree recorded and 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?

Bulleted, front-loaded and information-dense, with no filler sentences. Minor awkwardness ('turns the profile about about_mm as for add_extruded_profile' and the doubled 'about') slightly hinders parsing.

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

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

For a 9-parameter mutation tool with no annotations and no output schema, the description covers geometry modes, depth behavior, and the return value (mass properties). Not covered: interaction with feature history/naming, or errors on invalid/self-intersecting profiles.

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 description compensates thoroughly: points_mm dimensionality varies by mode (2D vs 3D), face, plane semantics with example values, about_mm as pivot for rotate_deg, depth_mm as blind vs through-all, keep_inside inversion, and corner_radii_mm. Only 'name' is undocumented, a minor omission.

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

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

Opens with a specific verb+resource: 'Cut a polygonal pocket, slot or window', which immediately separates it from sibling cutters like cut_slot and cut_offset_pocket by emphasizing arbitrary polygons. The auto-close behavior is noted up front.

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 mode-selection guidance: default +Z face, face='+x' for side pockets, plane= for side-view shapes, and keep_inside for intersect-two-views work. It does not explicitly say when to prefer this over cut_slot / cut_offset_pocket / cut_sketch, leaving one inference gap.

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 behavioral burden and does well by disclosing that the component and its holding mates are deleted, plus what is returned. It does not explicitly state irreversibility or undo behavior, which is a minor gap for a destructive operation.

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

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

The description is front-loaded with the action and scope, then efficiently covers the parameter and return values. Every sentence contributes useful 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 one-parameter destructive tool with no output schema and no annotations, the description supplies the needed purpose, parameter sourcing, deletion scope, and return values. An agent has enough information 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%, but the description fully compensates by explaining that component is the name from list_components, including exact examples and the single-match shorthand. This adds substantial 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?

The description uses a specific verb and resource: removing a component from the current assembly, and it explicitly includes the mates holding it. This clearly distinguishes it from related siblings like delete_mate and delete_feature.

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 context is clear: use this to remove a component and its holding mates from the current assembly. It does not explicitly name alternatives or exclusions, such as replace_component, but the intended use case is unambiguous.

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 burden and does well: it discloses the destructive effect (components are free to move again), the batch semantics with one rebuild, and the return content. It does not state irreversibility or what happens if a name 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?

Three short sentences, front-loaded with the action and scope, then bulk semantics, then return behavior. The parenthetical pointers are compact and each 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?

With one parameter and no output schema, the description covers input sourcing, bulk behavior, side effects, and return values, which is enough to invoke it correctly. Error cases and the suppress-vs-delete distinction are the remaining gaps.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains that the single 'name' parameter accepts either one name or a list, and that a list deletes all at once with one rebuild. It adds meaning beyond the anyOf schema, though it doesn't address matching rules or duplicates.

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") scoped to the current assembly and keyed by name, which separates it from delete_component and the geometry siblings. It does not explicitly contrast with suppress_mate, the nearest non-destructive alternative, so it stops short of a 5.

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

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

Tells the agent where names come from (list_components, or add_mate's 'mate') and documents the bulk form as deleting everything with a single rebuild, which is real usage guidance. It offers no explicit when-not or "use suppress_mate instead if you want to keep the mate" routing.

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

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

With no annotations at all, the description carries the full behavioral burden, and it does disclose two valuable things: the drawing is kept apart from the current part, and 'new' returns frame, title block and free areas in sheet mm. It says 'close' discards unsaved work, which is useful. However, it is silent on whether 'save' overwrites an existing file, whether open/save/export fail on missing paths, and whether operations are undoable.

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

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

The action enumeration is front-loaded in the first sentence, and the second paragraph adds two genuinely non-redundant facts (drawing/part separation, the return contents of 'new'). The nested parentheticals make it dense but every clause carries information.

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

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

For a four-parameter, multi-mode document tool with no annotations, no output schema, and zero schema descriptions, the definition does real work but not enough: sibling disambiguation, error behavior, and the save/export overwrite semantics are all missing, leaving the agent to guess on the risky paths.

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

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

Schema coverage is 0% (bare titles and defaults only), so the description has to carry parameter meaning and mostly does: it maps 'part' to the saved model whose views are shown, 'path' to .slddrw for open/save and to PDF/DXF/DWG/PNG/JPG/TIF for export, and 'sheet' to A4-upright or A3..A0. Gaps remain — the schema default for sheet is 'A3' while the description foregrounds 'A4' upright, and the interaction of 'part' with the other actions is unstated.

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

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

The description names a concrete resource (the current drawing's document) and enumerates five specific actions — new, open, save, export, close — with the argument shapes each accepts, so an agent knows exactly what the tool manipulates. It loses a point because several siblings (open_document, close_document, save_document, export, make_drawing) sound like they cover the same ground and the description never says how this tool differs from 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 is implied by the per-action argument notes: 'new' for fresh sheets, 'open'/'save' with a .slddrw path, 'export' for PDF/DXF/PNG output, 'close' without saving. But there is no explicit guidance on when to pick this tool over the sibling open_document, close_document, save_document or export tools, which is the most consequential decision an agent faces here.

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

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

No annotations, so the description carries the burden. It usefully discloses a side effect not visible in the schema: editing a model dimension persists changes in the part and the result reports changes_part. However, it does not state permissions, reversibility, or the full return shape, 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?

The core action and delete alternative are front-loaded in the first sentence, and the parameter notes follow in compact clauses. It is dense and slightly run-on, but nearly every clause carries parameter or behavioral information that 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 10-parameter mutation tool with no annotations and no output schema, the description is fairly complete: it names the resource, gives an id example, covers most parameters, and notes the changes_part result. Return format is only partially hinted at, keeping it short of 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 coverage is 0%, so the description must compensate, and it largely does: it explains prefix/suffix semantics (solidWorks symbol replacement with '4X R' example), precision=decimals, tolerance=[upper,lower] mm, fit='H7', text, at=[x,y] sheet mm, and diametric=True. Only a couple of params (annotation_id usage nuances, exact tolerance ordering) are lightly covered, but overall it fills the schema gap well.

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 ('Change an annotation by id') with a concrete id example ('RD3@Drawing View1') and the delete alternative. It is distinguishable from siblings like add_dimension/add_note (which create) and set_dimension, though it does not explicitly name its closest sibling to contrast with.

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

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

Implies usage by explaining how to set each field and offering delete=True as the removal path, but does not state when to use this versus set_dimension, add_dimension, or import_dimensions. The when-to-use context is inferred rather than explicit.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It does disclose that delete=True deletes the view and that projected/section views stay aligned and move only along that line, but it omits permission requirements, reversibility/persistence, side effects on dimensions or annotations, and return behavior. Clear gaps remain.

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

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

The definition is front-loaded with move/change/delete and every sentence carries information, including the valuable alignment caveat. The long parenthetical first sentence is dense but not 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 11-parameter mutation tool with no annotations, no output schema, and no schema descriptions, the description is largely complete: it covers the main operations, most parameter values, and the key alignment constraint. It still leaves some gaps around required name semantics and mutation side effects.

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

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

With 0% schema description coverage across 11 parameters, the description compensates well by defining at as [x, y], beside/side/gap_mm, align values, scale values, display modes, new_name, and delete=True. It does not explain the required name parameter or elaborate on tangent_edges, so it is not fully complete.

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

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

The opening sentence names the resource (a view) and three concrete operations (move, change, delete) with parameter syntax, so an agent can distinguish it from add_view and list_views. It is a specific verb-plus-resource description, not a tautology.

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 lists capabilities (move/change/delete) that imply when the tool is useful, but it does not explicitly say when to choose it over add_view or list_views, nor state prerequisites such as the view already existing. The guidance is inferable 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 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.