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

The description only restates the operation list; it does not disclose the key behavior that the target body is modified in place and, by default (keep_tools=false), the tool bodies are consumed. Annotations declare destructiveHint=false, so the fact that geometry is removed from the target is exactly the kind of context the description should surface. Nothing about selection requirements or failure modes is given.

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

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

A single front-loaded sentence with no filler. It is efficient, though its brevity borders on under-specification rather than precision.

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

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

An output schema exists and the input schema documents most parameters, so the burden is lighter. Still, for a geometry-mutating operation the description leaves out the in-place modification of target and the default consumption of tool bodies, both of which affect how an agent sequences calls.

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

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

Schema coverage is 75%: target, tools and keep_tools all carry descriptions, and the operation enum values are self-explanatory. The description's 'into target' reinforces the direction of the operation but adds no format or constraint detail beyond the schema. Baseline 3 applies.

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

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

Names the three concrete operations (unite, subtract, intersect) and the object they act on (bodies, into target), which is more specific than the bare tool name 'boolean'. No sibling tool performs booleans, so cross-tool confusion is low. It stops short of stating that a single target body is produced.

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

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

There is no guidance on when to use this versus the constructive siblings (sketch_extrude, revolve_sketch, create_box) or the modification siblings (move_body, delete_body). No preconditions, no mention of what state bodies must be in before the 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?

Annotations already declare this is a non-read-only, non-destructive, closed-world operation. The description adds the equal-distance beveling behavior and prerequisite context, but does not disclose further behavioral details such as reversibility or what happens to the original body.

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

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

The description is a single front-loaded sentence with no wasted text. It states the operation first and includes only one brief parenthetical prerequisite.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, for a required parameter with zero schema coverage, the description leaves the 'body' parameter unexplained and offers only partial usage guidance.

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 clarifies that edge_ids come from select_edges and that distance is an equal bevel distance, but the required 'body' parameter is not explained at all.

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

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

The description states a specific verb and resource: 'Bevel edges by an equal distance.' It is clear what the tool does, but it does not explicitly distinguish chamfer from the sibling fillet_edges operation.

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

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

The parenthetical '(get ids from select_edges)' gives a useful prerequisite for obtaining edge IDs, implying the tool should be used after select_edges. However, there is no explicit guidance on when to use chamfer_edges versus fillet_edges or other alternatives.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false. The description adds no behavioral context beyond geometry, such as how operation=cut affects targets or what happens with operation=add. It does not contradict annotations, but it contributes little behavioral 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 a single short sentence with no filler and front-loads the core shape constraint. It is concise, though its brevity comes at the cost of useful invocation context.

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 rich input schema, existing annotations, and an output schema, the description is minimally adequate for calling the tool. However, it omits the add/cut behavior and target interaction that distinguish this from a simple create-only 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 80%, so most parameters already have documented semantics. The description only implies corner_min/corner_max geometry and adds no meaning for name, targets, or operation beyond what the schema provides.

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

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

The description identifies the resource and geometric constraint (an axis-aligned block between two corners), but it is a noun phrase rather than an explicit action. It does not state that it creates a new body or can add to/cut targets, leaving the tool's full purpose only partially 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?

There is no guidance on when to use this tool versus siblings such as create_cylinder, create_sphere, or boolean. The description also does not mention the operation modes (new/add/cut) that determine the tool's effect.

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

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

Annotations declare destructiveHint=false, but the description explicitly advertises a cut mode that creates a round hole, i.e. subtracts material from an existing body. That is a destructive update, so the description conflicts with the annotation; other behavior such as target requirements and operation modes is left to 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?

It is a single sentence fragment, so it is concise but poorly structured for a 7-parameter tool. It front-loads the noun 'Cylinder' but omits the action, making it under-specified rather than optimally 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?

For a 7-parameter CAD mutation with conditional operation modes, the description is far too sparse. Output schema handles return values, but the description does not explain operation selection, target requirements, or body naming, leaving the agent to infer from the schema.

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

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

Schema description coverage is only 57%, and the description adds just one intuitive note that cut makes a hole of the given depth. It does not clarify name, radius, height, axis, or the conditional need for targets when operation is add or cut.

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 ('Cylinder') and mentions the cut variant, but it is a noun phrase with no verb and largely restates the tool name. It does not distinguish create_cylinder from shape siblings like create_box/create_sphere beyond the shape itself.

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

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

There is no guidance on when to use this tool versus create_box, create_sphere, or boolean for holes. The only usage hint is operation='cut', which describes a mode rather than an alternative-selection rule.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the agent knows this mutates model state without destroying geometry. The description adds the genuinely useful note that downstream solvers (Fluent, Mechanical) consume these groups, but says nothing about name collisions, invalid IDs, or what happens to an existing group with the same name.

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

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

A single dense sentence with the verb and resource front-loaded and the domain examples parenthesized rather than bloating the text. Nothing is wasted, though one more clause on the selection-parameter rule would have been worth the words.

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

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

An output schema exists, so return values need no explanation, and the domain framing is adequate for a moderately complex 5-parameter mutation. The missing piece is the parameter combination contract — an agent could call it with only 'name' and no geometry and have no textual warning that this is invalid.

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

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

Schema coverage is only 40%, and only 'body' and 'bodies' carry descriptions; face_ids, edge_ids and name are undocumented. The description hints that bodies/faces/edges are alternative things to group, but never states that at least one of bodies/face_ids/edge_ids must be supplied, nor that face_ids/edge_ids require the owning 'body' — the most important invocation constraint is left unstated.

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

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

States a specific verb ('Group') plus the exact resources (bodies/faces/edges) and the artifact produced (a name), which cleanly separates it from select_faces/select_edges in the sibling list. It stops short of naming those siblings, so the differentiation is inferential rather than explicit.

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

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

The parenthetical use cases (inlet/outlet/wall for CFD, fixed supports for FEA) imply when the tool is appropriate and 'Fluent and Mechanical pick these up' hints at cross-tool consumption. But there is no explicit when-not guidance and no stated alternative for one-off, non-persistent 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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is carried by structured data rather than the description. The description adds nothing beyond that — it never says a solid body is created, whether the operation is reversible, or what permissions/session state are required. No contradiction, but zero added value.

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 text is a single word, which is short but not concise in the useful sense — it is under-specified rather than front-loaded with information. Nothing is wasted, but nothing is communicated either.

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?

Even accounting for the existing output schema and annotations, a 5-parameter creation tool with an operation enum (new/add/cut) and a targets parameter needs more than one word. The description does not explain how the operation modes interact with targets or what gets created, leaving a significant gap.

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

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

Schema description coverage is only 40%: name, center, and radius are required but completely undocumented, and the description does not compensate at all. The meaning of center, radius, or the name collision behavior is left entirely to the agent's 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 'Sphere.' restates the resource named in the tool name and supplies no verb, scope, or outcome. An agent cannot tell from this text what create_sphere actually produces or how it differs from siblings like create_box or create_cylinder.

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

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

There is no guidance on when to use this tool, when to prefer boolean or create_cylinder instead, or what preconditions (e.g., an active design, a connected SpaceClaim session) must hold. The one-word description leaves routing entirely to the tool name.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds genuinely new context: the deletion is irreversible through the API. That is exactly the kind of consequence an agent needs before calling. It stops short of saying what else is destroyed (e.g., features referencing the body).

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

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

A single tight sentence with the operation stated first and the caveat appended. No filler, nothing that doesn't earn its place.

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

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

An output schema exists so return values need no explanation, and the irreversibility is disclosed. However, for a destructive tool with one fully undocumented parameter, the description should say how to identify a body and what happens to dependent geometry.

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

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

Schema description coverage is 0% for the single required 'body' parameter, and the description does not say how to supply it — name, ID, or handle. An agent must guess or infer from list_bodies/describe_body, which the description never mentions.

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: 'Delete a body from the design' tells the agent exactly what happens. There is no sibling delete tool, so no differentiation is required, but it also doesn't clarify scope such as whether sub-components or dependent features are affected.

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

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

The description gives no when-to-use or when-not-to-use guidance and names no alternatives. The only guidance offered is a caution ('there is no undo through the API'), which is a consequence, not a routing rule.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds useful context about the payload's structure and downstream ID usage, but it stays silent on the limit/pagination behavior and defaults that the schema hints at.

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

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

A single dense sentence that front-loads the returned content and ends with the actionable detail about IDs. It earns its place, though cramming both face and edge field lists into one line reduces readability slightly.

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

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

An output schema exists so return values needn't be described, and the ID hand-off to sibling tools is covered. However, for a 4-parameter tool with 25% schema coverage, the description should say what limit and the include_* toggles do, which it omits.

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

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

Schema coverage is only 25% (only `body` is documented). The description never explains `limit` (default 300, max 2000) or the `include_edges`/`include_faces` toggles, so it fails to compensate for the low coverage. An agent must guess what these three parameters do.

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 concretely states that it returns faces (with type, area, normal, radius, centre) and edges (type, length, ends, radius) of one body, plus the IDs that the face/edge tools consume. This distinguishes it from list_bodies (which presumably just enumerates bodies) and from the selection tools, but it lacks an explicit verb framing a describe operation.

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

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

It implies usage by noting it provides 'the ids that the face/edge tools take,' which hints it should be called before select_faces/select_edges/fillet_edges. But there is no explicit when-to-use vs alternatives, no exclusions, and no mention of when to skip include_edges/include_faces.

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

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

Annotations already declare that the tool is not read-only, not destructive, and closed-world, so the safety profile is partly covered. The description adds 'constant radius' and the select_edges workflow, but does not disclose that the operation modifies the body geometry, nor does it describe failure behavior or whether the change is reversible.

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

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

The description is a single, front-loaded sentence that states the operation, the key geometric constraint, and the prerequisite for obtaining edge IDs. 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?

The presence of an output schema means return values do not need explanation, and annotations cover the safety flags. Still, for a geometry-mutating tool with 0% schema parameter coverage, the missing explanation of 'body' and lack of guidance on invalid or incompatible edges leaves a noticeable gap.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies edge_ids by pointing to select_edges and implicitly clarifies radius as a constant rounding radius, but it does not explain the required 'body' parameter at all.

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: rounding edges with a constant radius. It distinguishes the operation from chamfer by the word 'Round', but does not explicitly name chamfer_edges as the alternative, so it falls short of full sibling differentiation.

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

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

The parenthetical 'get ids from select_edges' gives a useful prerequisite for the edge_ids parameter. However, it does not explain when to use this tool versus chamfer_edges, or mention any limitations such as invalid edge selections or non-fillettable geometry.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the returned metrics (volume, bbox, topology counts), but says nothing about scope (all bodies? visible only?), ordering, or cost of refresh.

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

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

One tight sentence that front-loads the resource and the payload. No waste, though it's arguably too terse to route an agent between this and describe_body.

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

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

With an output schema and read-only annotations present, the description needn't explain return shapes. The one remaining gap is how this relates to describe_body for an agent choosing between the two.

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

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

Schema coverage is 100% and the single 'refresh' parameter is fully described in the schema as a re-read after UI edits. The description adds nothing about parameters, so baseline 3 applies.

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

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

States a clear verb-resource pair implicitly ('list' + bodies) and enumerates the key returned attributes (volume, bounding box, face/edge counts), which tells an agent what the tool surfaces. It doesn't explicitly contrast with describe_body, so sibling differentiation is left to inference.

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

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

No statement of when to use this versus describe_body (single-body detail) or measure_distance. No guidance about the refresh parameter's role or when a re-read is needed.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. The description adds the result vocabulary (none/touch/intersect/contained), which aids interpretation, but says nothing about units, tolerance, or cost of the computation.

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

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

A single sentence, front-loaded with the operation and immediately followed by the possible outcomes. Every clause carries information; 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 two-parameter read-only measurement with an output schema and full annotation coverage, the description covers purpose and result interpretation adequately. It falls short only on prerequisites and units of the returned distance.

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

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

Schema coverage is 100% and both parameters are documented as 'Body id or unique name', so the heavy lifting is done by the schema. The description adds no constraint or format detail beyond that, so the baseline 3 applies.

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

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

The description states a specific measurement resource (minimum distance between two bodies) and the collision classification it produces, which no sibling tool offers. It is clear but never explicitly distinguishes itself from related siblings like describe_body or list_bodies.

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

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

Usage is only implied by the subject matter — an agent can infer you call it to check clearance between two bodies. There are no explicit when/when-not conditions, no mention of alternatives, and no stated prerequisites such as both bodies needing to be present in the active design.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is known. The description adds a genuinely useful behavioral detail — operations are applied in translate → rotate → mirror order — but it omits the copy/original-preservation semantics and any mention of what happens if only some of the three operations are supplied.

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

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

A single sentence, zero filler, and the most decision-relevant fact (order of application) is front-loaded. Every clause earns its place.

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

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

An output schema exists, so return values need not be described. However, for a 5-parameter mutation with only 40% schema coverage, the description does not clarify how omitted operations behave, what 'copy' leaves behind, or prerequisites (bodies must already exist / be referenced by name).

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 40%, but the nested Rotation and MirrorPlane fields carry their own descriptions (axis, angle, origin, normal). The description's order-of-application statement is real semantic value over the schema, since it tells the agent that combining translate+rotate+mirror composes in a fixed sequence. It adds nothing about the copy flag or translate offset beyond schema text.

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 three specific transformation verbs (translate, rotate, mirror) and the resource (bodies), and even states the order of application. It clearly delineates the tool from siblings such as pattern_body or delete_body, though it doesn't explicitly call out an alternative.

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

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

Usage is implied: it's the tool to reach for when a body must be repositioned or duplicated ('copy'). But there is no explicit when-to-use vs when-not guidance, no exclusions, and no mention of when pattern_body might be the better sibling.

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

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

Annotations already flag destructiveHint=true, and the description earns its keep by explaining exactly what is destroyed: the currently open design is closed and unsaved work is lost. It stops short of saying what happens to the previous design's file or whether a save prompt appears.

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

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

Two short sentences, front-loaded with the action and followed by the risk warning. Nothing is wasted.

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

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

With an output schema present and annotations covering the safety profile, the description supplies the key missing piece (the destructive side effect on the open design). Only the naming parameter is left unexplained.

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

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

The single optional 'name' parameter has 0% schema description coverage and the description never mentions it, so an agent learns nothing about naming the new design or the 'Design1' default beyond what the raw schema shows.

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 an empty design') and immediately clarifies the side effect on the currently open design, which cleanly separates it from save_design and open_file among the 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?

Explicitly gives a precondition: call save_design first if the current design has unsaved work. That names the alternative and the condition, though it does not discuss other cases such as when to use open_file instead.

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

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

Annotations already declare destructiveHint=true, and the description adds real value by disclosing exactly what is destroyed—the current design—which is the crucial operational fact. It stops short of warning about unsaved changes or prompting a save, so a small gap remains.

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

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

A single sentence with the destructive side effect front-loaded in parentheses; nothing is wasted.

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

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

Output schema exists, so return values need no explanation, and the single required parameter is fully documented in the schema. The only missing element is the unsaved-work implication of closing the current design.

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

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

Schema coverage is 100% and the path parameter already enumerates supported formats, so the schema carries the burden. The description adds no format or path syntax detail beyond it, making baseline 3 appropriate.

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

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

States a specific verb (open) and resource (CAD file), plus the resulting state ('as the active design') and its side effect. It implicitly distinguishes itself from new_design by naming a file path rather than creating a blank design, though it never names the sibling.

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

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

Usage is implied by the parenthetical that the current design closes, which hints at when this applies versus new_design. There is no explicit when-to-use guidance, prerequisites, or named alternative.

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

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

Annotations already declare this is a non-read-only, non-destructive operation, and 'Copy' is consistent with that. The description adds that the tool creates patterned copies, but it does not explain side effects such as whether the original body remains, how new bodies are named, or how 'unite' changes the outcome.

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

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

The description is a single tightly written sentence with no wasted words. The core operation is front-loaded, and the parenthetical examples add useful context without bloat.

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 an output schema, annotations, and strong schema descriptions, so the description need not explain return values or most parameter behavior. It identifies the resource and both pattern modes, though it could say a bit more about how linear and circular modes differ in required inputs.

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

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

Schema description coverage is high at 78%, so the schema already documents most parameters including spacing, direction, axis, axis_origin, total_angle, and unite. The description adds conceptual mapping by mentioning 'a row' and 'around an axis', but it does not add syntax or constraints beyond the schema.

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

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

The description states a specific verb and resource: 'Copy a body', and clarifies the two modes ('in a row or around an axis') with concrete examples. It is clear enough to distinguish from most siblings, but it does not explicitly differentiate itself from related tools like move_body or boolean.

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

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

The phrase 'bolt circles, rib arrays' implies typical use cases, so the agent can infer when this tool is appropriate. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives for related operations such as move_body or boolean.

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

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

Annotations already declare that the tool mutates geometry, is non-destructive, and is closed-world. The description adds useful context that only planar faces are pulled and gives sizing examples, but it does not explain side effects on adjacent geometry, reversibility, or selection prerequisites.

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 operation and followed by a useful exclusion. Every sentence carries actionable information without redundant restatement.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a mutation tool with low parameter coverage, the description omits prerequisites such as selecting a body or faces and does not clarify adjacency or failure constraints.

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

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

Schema coverage is only 33%: distance is documented in the schema, while body and face_ids have no schema descriptions. The description adds only the planar-face constraint for face_ids, but does not explain the body identifier format or where face IDs come from.

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 specific operation (offset planar faces) and the outcome (change size, thicken a plate, deepen a pocket). It also distinguishes this from hole resizing by explicitly naming the alternative approach.

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 examples and an explicit when-not-to-use case, directing hole resizing to cutting a larger cylinder instead. This leaves little ambiguity about selecting this tool versus an alternative.

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

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

Annotations already declare a non-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the safety profile is covered. The description adds nothing beyond that: it does not say whether the rename affects references, whether names must be unique, or whether an existing name causes an error.

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

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

One short, front-loaded sentence with zero waste, but its brevity reflects under-specification rather than efficiency — nothing beyond the title is conveyed.

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

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

An output schema exists so return values need not be explained, but for a mutation tool in a CAD session the description should still say how to identify the target body and what validation applies to the new name. Those essentials are missing.

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

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

Schema description coverage is 0%, so the description carries the full burden of explaining that 'body' identifies the target via name or ID and what constraints apply to 'new_name'. It provides none of this, leaving both required parameters with no semantics beyond their self-explanatory labels.

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 "Rename a body" restates the tool name almost verbatim, qualifying as tautology rather than an independent statement of purpose. It does not distinguish the tool from siblings such as move_body, delete_body, or describe_body beyond the implied verb difference.

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

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

There is no guidance on when to use this versus alternatives, no prerequisites (e.g., that the body must exist and be connected to an active design), and no exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds workflow context (use as a checkpoint) but says nothing about the return artifact — image vs. text, resolution tradeoffs, or cost of rendering — which is the behavior an agent most needs here.

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

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

Two tight sentences, front-loaded with the output description then the usage rule. Nothing is redundant and no sentence could be dropped without losing 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?

Six optional parameters, no output schema, and only 50% schema coverage. The description establishes the workflow role well but leaves gaps on what actually comes back (single image vs. 2x2 sheet, resolution effect) that an agent needs in order to choose size/views sensibly.

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

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

Schema coverage is 50%: views and bodies are documented inline, while size, highlight_edges and highlight_faces have no schema descriptions. The description gives a purpose for the highlight parameters (confirm a selection before filleting/cutting), adding real meaning, but never mentions size or multi-view output, leaving half the surface 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 concrete output — 'a shaded picture of the model' — which is clearly distinct from every sibling (modeling, selection, measurement tools). The verb is implied rather than stated ('render'), but the resource and result are unambiguous.

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

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

Gives explicit timing guidance — after every few edits and before reporting a result — and a concrete verification pattern tied to siblings (highlight faces/edges before filleting or cutting). It stops short of naming when *not* to call it or naming a visual alternative, so it is not a full 5.

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

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

Annotations already declare this as a non-read-only, non-destructive, non-open-world mutation, so the safety profile is covered. The description adds genuine geometric validation rules (axis must lie in the sketch plane, must not cross the profile) that are not in annotations or schema. It stops short of describing what happens on constraint violation or how new/add/cut differ behaviorally, keeping this at a moderate 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?

Two sentences, zero waste, and front-loaded with the core action before the constraint. The constraint sentence earns its place by preventing a common geometric error.

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 eight-parameter tool with seven profile variants and an output schema, the description covers only the action and one geometric constraint. Operation modes, angle limits, and plane selection are handled by the schema, so nothing critical is missing, but the description could add more domain guidance (e.g., that operation=new creates a separate body) to be complete.

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

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

Schema coverage is moderate (63%) and the schema itself richly documents operation semantics, plane behavior, and shape variants. The description does not explain the axis, angle, or plane parameters beyond the plane-membership constraint already implied. With the schema doing most of the parameter documentation, baseline 3 is appropriate.

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

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

The description states a specific verb and resource: "Revolve sketch profiles about an axis," and adds concrete example artifacts (shafts, pulleys, turned parts) that make the purpose tangible. It does not name the sibling sketch_extrude to differentiate when to revolve versus extrude, but the verb itself is distinct enough for an agent to select it over the extrusion tool.

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

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

The parenthetical examples (shafts, pulleys, turned parts) imply typical use cases, and the axis constraints imply preconditions. However, there is no explicit "use this instead of sketch_extrude when..." routing, and no named alternatives or exclusions, leaving the agent to infer selection from the examples alone.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, so the agent knows this is an unsafe write operation. The description adds one genuinely useful behavioral fact — "the design is re-read afterwards" — implying the model state may change outside the tool's tracking and subsequent reads matter. It omits the bigger risks: that arbitrary code executes with full API access, whether it runs in the live session, failure/recovery behavior, or what happens to existing geometry.

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

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

Two short sentences, zero waste, with the escape-hatch framing front-loaded so the routing decision is made immediately. The design re-read note is terse but carries real 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 destructive arbitrary-code tool, the combination of description, destructive annotation, full schema coverage, and an output schema covers the essentials: what it does, when to reach for it, and how to pass inputs and retrieve outputs. It is slightly thin on execution environment and failure semantics, which matter more here than for a typed 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 100%, and the schema itself explains argsDict, the result dict with string values, and the IronPython/SpaceClaim API constraint. The description adds nothing about either parameter, so the baseline 3 applies — the schema is doing all the work here.

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

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

States a specific verb and resource ("run a script inside the product") and explicitly positions itself as the escape hatch for gaps the typed tools leave. It is distinguishable from every sibling at a glance. It stops short of a 5 because "the product" is never named and the script language/API is only discoverable in the schema, not the description.

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 an explicit when-to-use rule: "anything the typed tools do not cover," which implicitly routes the agent to try typed tools like fillet_edges or boolean first. It does not state when-not to use it (e.g., never for operations a typed tool already supports) or what prerequisites like an active connection are required.

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

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

The description states 'An existing file is replaced', which is a destructive overwrite behavior. However, annotations declare destructiveHint: false, creating a direct contradiction. The description also lacks other behavioral context (e.g., permissions, error handling), but the contradiction alone warrants a score of 1.

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

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

The description is two short sentences with zero waste, front-loaded with the primary action and immediately followed by the critical overwrite note. Every sentence earns its place.

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

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

Given the simplicity of the tool, the rich parameter schema, and the presence of an output schema, the description covers the essential behavioral trait (file replacement). Minor details like whether a new file is created or required preconditions are omitted, but these are largely inferable.

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

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

Schema coverage is 100%, and the schema's path description is highly detailed, covering file extensions and relative path behavior. The description adds no parameter-level information beyond what the schema already provides, which meets the baseline of 3.

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

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

The description states a specific verb 'save or export' and resource 'active design', making the purpose clear. It does not explicitly differentiate from siblings like open_file, but the verb and context are sufficient for an agent to identify it.

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

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

Usage is implied – save or export the active design – but there is no explicit guidance on when to use this vs alternatives, nor any conditions or exclusions. An agent must infer the context from the tool name.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered and the description need not repeat it. It does not disclose whether the call mutates the current selection set or merely returns matching edges, nor whether filters combine as AND or OR — meaningful behavioral gaps for a tool named select_*, given an output schema exists to cover return shape.

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

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

A single parenthetical sentence that front-loads the core purpose and spends its remainder on the highest-value disambiguation. No filler, nothing repeated from annotations or schema.

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

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

With 9 parameters, present annotations and an output schema, the description is serviceable but thin: it omits how simultaneous filters interact, whether results replace the active selection, and what body references are accepted. The examples compensate partially but leave an agent guessing on filter composition.

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 67%, and the description's examples map usefully onto specific parameters: "vertical edges" to parallel_to, "edges of the top face" to on_faces, "Ø8 hole rims" to radius. That is genuine semantic grounding beyond the schema text, though max_length, min_length and radius_tolerance remain undocumented in both places.

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

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

States a specific verb ("Find") and resource ("edges") and pins down the domain with concrete geometric examples (vertical edges, top-face edges, Ø8 hole rims). The resource noun alone separates it from the sibling select_faces, but the description never explicitly names that sibling or the other retrieval tools.

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

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

The examples imply the usage context (locating edges for downstream operations like fillet_edges or chamfer_edges), but there is no explicit statement of when to call this versus select_faces, describe_body, or measure_distance. No exclusions or prerequisites are given; an agent must infer the workflow position.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world scope, so safety is covered. The description adds that selection is geometry-driven rather than id-driven, but says nothing about whether multiple filters are combined as AND, what happens with zero matches, or how results feed downstream operations.

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

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

A single front-loaded sentence with no waste, and the geometry-over-ids differentiator leads. It is arguably too terse for a 9-parameter filter tool, 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a 9-parameter boolean-style filter with only 56% schema coverage, the description omits how filters compose and what tolerance parameters mean, leaving 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 coverage is 56%, and the description's examples implicitly map to parameters ("top face" → extreme=max_z, "Ø8 holes" → radius + surface_type). That adds some intuition, but min_area/max_area, normal_tolerance and radius_tolerance get no explanation in either place, and the filter-combination semantics are unstated.

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

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

States a specific verb and resource ("Find faces") and contrasts the approach with id guessing, with two concrete examples ("top face, all Ø8 holes"). It is clearly distinguishable from select_edges by resource, though it doesn't name that sibling.

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

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

The phrase "instead of guessing ids" implies when to prefer this tool over id-based selection, which is useful. But there is no explicit when-to-use/when-not guidance and no mention of select_edges or follow-up tools like pull_faces.

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

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

Annotations already state this is a non-read-only, non-open-world, non-destructive operation. The description adds operation-specific behavior about wall thickness and opening faces, but does not disclose whether the original body is modified in place, what failures occur for non-solid bodies, or units/validation constraints.

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

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

The description is a single front-loaded sentence with no filler. It states the operation and its optional extension efficiently.

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

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

The core operation is conveyed, and the output schema plus annotations reduce the need to explain returns and safety. Still, for a mutating CAD tool it omits important context such as whether the body is modified in place, what happens when thickness is too large, and how side affects the result.

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

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

Schema coverage is only 50%, so the description helps by clarifying thickness as wall thickness and open_faces as optional face removal. However, it does not explain the side parameter or add more detail for body, leaving the remaining semantics mostly to the schema.

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

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

The description names a specific CAD operation and outcome: hollowing a solid to a wall thickness, with optional open faces. It is clear enough to distinguish from most siblings such as boolean or pull_faces, though it does not explicitly route against 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?

It implies the operation when a hollow shell is desired, but gives no explicit when-to-use guidance, prerequisites, exclusions, or comparison to sibling tools like boolean or pull_faces.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the description need not carry the full safety burden. It adds that the result is a solid, but does not disclose that 'add' or 'cut' require targets or that 'cut' subtracts from every target—behavioral context that would help an agent avoid mis-invocation. With annotations already covering safety, a 3 is appropriate.

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

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

The single sentence is front-loaded with the core action and free of filler. It is appropriately sized for a high-level summary, though its brevity is also the source of missing usage guidance.

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 complex CAD operation with 7 parameters, multiple shape types, three operation modes, and optional target bodies. The description explains only the broad sketch-and-extrude concept and leaves out how 'add'/'cut' interact with targets, what happens if required parameters are missing, or how to choose between a principal plane and a face. Even with a rich schema and an output schema, the description is too thin to fully orient an agent for correct invocation.

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

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

Schema description coverage is 57%, so the schema already documents many parameters including the rich shape and plane definitions. The description adds only that sketching can occur on a plane or planar face, implicitly mapping to the 'plane' parameter, but says nothing about 'name', 'distance', 'targets', or 'operation'. Baseline 3 when schema does substantial work.

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

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

The description states a specific verb pair ('sketch 2D shapes ... and extrude them into a solid') and resource, making the tool's core purpose immediately clear. It does not explicitly name or differentiate from sibling tools like revolve_sketch or create_box, so it falls just short of a 5.

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

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

The description mentions 'plane or planar face' as a sketching context, but gives no guidance on when to use this versus revolve_sketch, create_box, or boolean. It also omits any mention of the operation modes ('new', 'add', 'cut') that are central to deciding how to invoke the 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?

Goes well beyond the annotations by disclosing real side effects: launching starts the product with its API server add-in, reconnecting tears down the previous connection first, and a server-launched product dies with the server. It also gives a concrete latency window (30-120 s), which matters for an operation the annotations only flag as non-read-only.

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

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

Three short sentences, front-loaded with what the tool does, followed by the two behavioral facts an agent must know (latency and connection lifecycle). No filler or restatement of the title.

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

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

With an output schema present, the description needn't explain returns, and it adequately covers the connection lifecycle. It could still note that this must be called before the other spaceclaim_* tools and that the product defaults to an environment variable, but the schema carries those details.

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

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

Schema description coverage is 100%, so every parameter including mode, product, version, transport_mode, and timeout is already documented in the schema. The description adds no parameter-level detail (e.g., how timeout interacts with the 30-120 s launch, or when hidden should be set), so the baseline 3 applies.

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

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

States a specific verb and resource — start (or attach to) SpaceClaim/Discovery and make it the target. This is clearly distinguishable from siblings like spaceclaim_disconnect, spaceclaim_status, and new_design 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?

The two operating modes (launch vs attach) are described with their consequences, and the 30-120 s launch warning implicitly tells the agent to call this early and budget time. It never explicitly names an alternative tool or states exclusions (e.g., call spaceclaim_status to check an existing connection first), 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?

Annotations already declare destructiveHint=true, and the description goes well beyond them by explaining the conditional consequence: a server-launched product exits and unsaved work is lost, while an attached product keeps running. That per-deployment divergence in blast radius is exactly the behavior an agent cannot infer from the annotations or 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?

Two short sentences, the core action front-loaded and the risk condition immediately following. No filler, no 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?

With zero parameters and an output schema present, the only thing an agent genuinely needs is what happens to the live session and any unsaved work — and the description delivers precisely that. Nothing material is missing for a correct invocation.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline applies. The description correctly adds no parameter noise.

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 ('Close the connection'), and contrasts the two session modes (server-launched vs attached) so the agent understands what is being torn down. It does not name the sibling 'spaceclaim_connect' as its counterpart, but the operation is unambiguous.

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

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

Usage is implied rather than stated: the agent can infer this is the terminal cleanup step, and the '(unsaved work is lost)' parenthetical hints at saving first. There is no explicit 'call this when finished' guidance, no instruction to pair it with save_design, and no statement about reconnect behavior.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds what is actually returned (backend version, working unit, open design), which goes slightly beyond annotations, but it omits behavior in the error case — whether it fails or returns a disconnected state when no session exists.

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

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

A single short clause with no filler, and the most important item (connection state) is front-loaded. It loses a point only because the elliptical fragment style sacrifices clarity for brevity.

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

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

With an output schema present and zero parameters, the description need not explain return structure, so the remaining burden is small. Still, for a status/probe tool the key missing piece is when to call it (e.g., before running operations on a design), which leaves it only minimally viable.

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 baseline of 4 applies. The listed fields act as an informal output preview even though a real output schema exists.

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 enumerates the four pieces of information reported (connection state, backend version, working unit, open design), which is more specific than a tautology, but it is a noun fragment with no verb — the agent must infer that the tool *reports* these. It is distinguishable from connect/disconnect siblings, but only by implication of the name rather than an explicit statement.

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

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

There is no guidance on when to call this versus spaceclaim_connect or spaceclaim_disconnect, no mention of ordering (e.g., call before other operations to verify a session), and no statement of what happens if the backend is not connected. Usage is only implied by the name.

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