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

The description adds a genuine prerequisite beyond the annotations: existing documents require allow_edit=true before modeling, which is meaningful operational context. But annotations declare destructiveHint=true and idempotentHint=false while the description never explains what is destroyed (e.g., unsaved changes in the previously active document) or why re-activation is non-idempotent — the highest-risk behavior of this tool is left unexplained.

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 purpose and followed immediately by the practical constraint. No filler; the only weakness is that the brevity comes at the cost of missing safety-relevant detail.

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

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

For a two-parameter tool this covers the basic call pattern, and no output schema exists so return values need not be explained. However, given destructiveHint=true, the absence of any statement about what state is affected or overwritten leaves a real gap in what an agent needs to call this safely.

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

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

Schema coverage is 0%, so the description carries the burden. It successfully explains allow_edit semantics (must be true for existing documents, default false), but leaves "title" ambiguous — document display title versus filename or path is not clarified, which matters for targeting the correct document.

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

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

"Explicitly target an open document" names a verb (target/activate) and resource (document), so the general intent is inferrable, but "target" is vague about what activation actually does (sets an active editing context?) and the description never distinguishes this from siblings like open_part, new_part, or list_documents.

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

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

The clause "before modeling" implies the tool is a precursor step to feature operations, and the allow_edit note implies a checkpoint before editing existing documents. However, no alternative is named (e.g., when to call this versus open_part or new_part), and no explicit when-not-to-use case is given.

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

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

The annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so much of the safety profile is carried for the description. In return the description adds a genuinely useful unit convention (mm, degrees, kg) and signals that measurements and error evidence come back. It never says what is modified or destroyed when a boss is placed, and the "independent native SOLIDWORKS engine" phrase is opaque.

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 with the purpose front-loaded, so there is little waste. However, two of the three sentences are generic boilerplate that could appear on any tool in this family, and "Inspect verified measurements and error evidence" is vague enough to add little actionable 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?

This is a destructive geometry mutation with 8 undocumented parameters and no output schema, which is exactly the case where the description should do heavy lifting. It omits the face-reference format, the meaning of from_edges, the effect of the name default, and any statement about what happens on failure, leaving the agent unable to call it reliably from the definition alone.

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

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

Schema description coverage is 0% across 8 parameters, so the description carries the full burden and only partially meets it: the mm/degrees/kg statement explains the unit suffixes on x_mm, y_mm, z_mm, height_mm, and diameter_mm. The most consequential parameters, `face` (what reference format is accepted) and `from_edges` (what it changes about placement), get no explanation 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 ("Add boss on face"), which is enough to separate it from additive siblings like add_box or add_cylinder. It does not explicitly distinguish itself from the closest neighbors add_hole_on_face, add_text_on_face, and add_extruded_profile_on_face, so an agent must infer the difference from the name 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?

There is no guidance on when to choose this tool over add_extruded_profile_on_face or add_hole_on_face, nor any stated prerequisites such as an active document or a valid face reference. The only directive, "Inspect verified measurements and error evidence," concerns what to do after the call, not when to make it.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context the annotations lack: it runs through an "independent native SOLIDWORKS engine", uses mm/degrees/kg public units, and surfaces verified measurements plus error evidence. However, it never explains why an "add" operation is flagged destructive or what existing state it affects, which is the key behavioral question left open.

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

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

Three short sentences with the action front-loaded and no filler. The closing sentence about inspecting measurements is slightly vague but still earns its place as workflow 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 mutating geometry-creation tool with four parameters at 0% schema description coverage and no output schema. The description covers units and hints at verification, but leaves the `name` parameter, dimension constraints, target document, and result shape undocumented — significant gaps for a destructive 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%, so the description must carry the parameter burden, and it only partially does: the "public geometry units are mm" line confirms the unit convention for width/height/depth. It says nothing about the optional `name` parameter (default "BlockExtrude"), nor about the exclusiveMinimum > 0 constraint on the three dimensions.

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 ("Add box") and names the execution engine, so an agent can tell it apart from add_cylinder, add_cone, or add_disc by the shape keyword alone. It never explicitly contrasts with those siblings, so it falls short of a 5.

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

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

There is no statement of when to use this versus add_extruded_profile, extrude_sketch, or the other solid-creation siblings, and no prerequisites such as an active document being required. "Inspect verified measurements and error evidence" hints at a post-call verification workflow but gives no condition for choosing this tool.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=false and non-idempotent, so the safety profile is covered. The description adds two useful facts beyond that: all geometry is expressed in mm/degrees/kg, and results include verified measurements plus error evidence. It does not say what geometry is consumed or modified, nor that defaulting edges to "all" affects the entire body, which matters for a destructive feature.

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 with the operation front-loaded and no filler. The final sentence about inspecting measurements is slightly vague in phrasing but still earns its place by hinting at the return shape.

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 5-parameter modeling operation with no output schema and zero schema descriptions, the definition leaves the most decision-relevant parameters (edges, from_face) unexplained and never describes the error-evidence structure it references. An agent could call it, but only by guessing at edge selection 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 description coverage is 0% across 5 parameters, so the description must carry the burden. It clarifies the unit system for distance_mm and angle_deg (mm, degrees), which is genuine added meaning, but says nothing about edges (default "all", selection syntax), from_face, or the name parameter's role.

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

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

The description states a specific verb and resource ("Add chamfer") and names the engine that executes it, so an agent knows this creates a chamfer feature rather than, say, a fillet (add_fillet) or full round (add_full_round). It stops short of explicitly contrasting those siblings, but the operation name itself is distinctive enough to route correctly.

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

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

There is no statement of when to use this tool, what preconditions must hold (an existing body, valid edge references), or which sibling to pick when a rounded vs. beveled edge is desired. The only usage-adjacent content is a unit convention, which is a data convention rather than 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, readOnlyHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds unit conventions (mm, degrees, kg) and a vague hint about inspecting "verified measurements and error evidence," but never states what geometry is destroyed, whether the pattern is additive to the feature tree, or how failures are surfaced — the boilerplate phrasing about "the independent native SOLIDWORKS engine" conveys nothing actionable.

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 with the operation front-loaded, but the middle sentence about the "independent native SOLIDWORKS engine" is marketing filler, and the closing "inspect verified measurements and error evidence" is vague enough to add little. Space that could document parameters is spent on boilerplate.

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 destructive mutation with no output schema, no annotation-adjacent explanation of effects, and zero parameter documentation — the agent cannot determine from the definition which feature gets patterned or what happens on failure. Given the tool's complexity and the 0% schema coverage, the description falls well short of what is needed to invoke it correctly.

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

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

Schema description coverage is 0% across four parameters, so the description must carry the burden and it does not. It implies mm for the two center coordinates via the unit sentence, but says nothing about what count means (minimum 2, angular distribution?), how the circular pattern's axis/angle is determined from only a center point, or what feature_name selects.

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?

"Add circular pattern" names a specific verb and resource, and the sibling list makes the contrast with add_linear_pattern/add_mirror obvious from the name alone. However, the description never says what is being patterned — no source feature, body, or sketch is identified even though none of the required parameters appear to reference one, which leaves the core operation underspecified.

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

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

There is no when-to-use guidance at all: nothing tells the agent to prefer this over add_linear_pattern, add_mirror, or a manual repeated feature, and no prerequisite state (open document, existing feature) is mentioned. The only routing signal is the tool name itself.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the mutation profile is covered. The description adds useful context — that geometry uses a native SOLIDWORKS engine and that results include verified measurements and error evidence — but omits what gets modified in the document and whether an existing body is affected.

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

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

Three short sentences with the core action front-loaded and no filler. The final sentence about measurements and error evidence is a bit vague but does not bloat the text.

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

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

For a destructive solid-creation tool with no output schema and zero parameter documentation, the description leaves significant gaps: no statement of required document state, of what is created or replaced, or of parameter interpretation. The unit declaration is the only substantive addition.

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 none of the four parameters are named in the description. The unit statement (mm, degrees, kg) gives partial meaning to the numeric fields, but it does not clarify the relationship between bottom_diameter and top_diameter (e.g. whether a zero top diameter yields a true cone) or the role of the name 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?

States a specific verb and resource (add a cone) and names the underlying engine, making it distinguishable from siblings like add_cylinder or add_disc. It does not explicitly contrast with those siblings, but the resource name 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?

No when-to-use guidance, no prerequisites (e.g. requires an active part document), and no mention of alternatives such as add_cylinder or add_revolved_profile. The agent must infer context entirely.

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

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

Annotations already declare destructive=true, idempotent=false and openWorld=false, so the mutation risk is covered structurally. The description adds the unit convention and mentions inspecting verified measurements and error evidence, which hints at a validation/report step. It still does not say which body or face the hole is added to, whether the act is reversible, or what happens when the diameter constraints fail.

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?

Short and front-loaded with the operation, which is good. The closing sentence ("Inspect verified measurements and error evidence") is vague filler that does not tell an agent what is verified or what form the evidence takes.

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

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

A destructive 6-parameter modeling mutation with no output schema and zero schema description coverage needs more than three sentences. Placement semantics, geometric validity rules and the success/failure response are all left unspecified.

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 whole burden, yet it only supplies units (mm for the length parameters). It never explains what the x_mm/y_mm pair is positioned relative to, nor the relationship required between clearance_diameter_mm and cbore_diameter_mm, leaving five required numeric parameters semantically thin.

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 ("Add counterbore hole") and names the engine it drives, which is enough to know the operation. It does not distinguish itself from siblings such as add_hole, add_hole_on_face or add_hole_wizard, so an agent cannot tell from the text why it would pick this variant.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of prerequisites such as requiring an active part or a target face/body. Given the cluster of related hole tools in the sibling list, the absence of routing guidance is a real 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?

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=false, so the description carries a lower burden — but it adds almost nothing: it never says the operation mutates the active document, adds a body, or is irreversible. 'Inspect verified measurements and error evidence' gestures at post-call behavior without explaining what evidence is returned or what state changes 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?

Three short sentences and front-loaded with the core action, which is good. The middle sentence about the 'independent native SOLIDWORKS engine' earns little, and the final sentence is vague enough that it consumes space without conveying actionable 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?

A mutation tool with no output schema should clarify what gets created, where it lands, and what the caller receives; this description leaves all of that ambiguous. Given zero parameter documentation coverage and destructive semantics, an agent lacks what it needs to call this confidently beyond the bare minimum.

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 all three parameters, but it only asserts units (mm, degrees, kg) — and the unit for diameter_mm/height_mm is already encoded in the property names. The optional 'name' parameter (defaulting to 'Revolve') is never mentioned, leaving a non-obvious naming behavior undocumented.

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

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

States a specific verb+resource ('Add cylinder') that is immediately distinguishable from siblings like add_cone, add_disc and add_box. However, 'through the independent native SOLIDWORKS engine' is positioning language rather than a functional differentiator, so the purpose is clear but not enriched.

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

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

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites (e.g. an open part document), and no routing to alternatives such as add_cone or add_revolved_profile for similar geometry. The agent must infer usage entirely from the 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 this a destructive, non-idempotent, non-read-only write, so the safety profile is covered. The description adds two genuinely new facts: public geometry units (mm/degrees/kg) and that the result includes verified measurements and error evidence. It still omits which document/body is modified and whether an existing body is affected.

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

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

Three short sentences with the action front-loaded and no filler. The closing sentence about inspecting measurements and error evidence is somewhat cryptic 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 five-parameter, zero-coverage mutation tool with no output schema, the description answers almost none of the questions an agent would have: target document, positional semantics, and what the response contains. Units and an error-evidence hint are not enough to call it safely.

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

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

Schema description coverage is 0% across five parameters, so the description must compensate and largely does not. It clarifies units for the dimensional fields but says nothing about x_mm/y_mm (presumably the disc center location), the name default, or how the two required fields relate to each other.

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?

"Add disc" names a specific verb and resource, and the mention of the native SOLIDWORKS engine establishes the modeling context. It does not explicitly contrast with nearby primitives like add_cylinder, add_cone, or add_extruded_profile, so sibling differentiation is only implicit.

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

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

The description never states when to use this instead of add_cylinder, add_extruded_profile, or add_revolved_profile, nor does it state prerequisites such as an active document. The only usage-adjacent signal is the unit convention.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation profile is known. The description adds a genuinely useful convention (public geometry units are mm, degrees and kg) and hints that the result carries measurements and error evidence, but it never says what geometry is created or destroyed, whether the body merges into existing geometry (the merge flag), or what failure modes look like.

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, with no filler. The closing sentence about "verified measurements and error evidence" is somewhat cryptic boilerplate, but the overall length is well matched to a small description.

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

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

For an 8-parameter, 0%-documented, destructive modeling operation with no output schema and many near-identical siblings, the description is far too thin. An agent cannot determine required input shape beyond the field names or predict what the call will produce.

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 8 parameters, so the description carries the burden — yet it only supplies units. Nothing explains that points_mm must be at least three [x, y] pairs forming a closed polygon, what about_mm does, whether corner_radii_mm accepts a scalar versus a per-corner array, or how merge and name affect the result.

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?

"Add extruded profile" gives a verb and a resource, but it essentially restates the tool name and the extrusion family is enormous here (add_extruded_profile_on_plane, add_extruded_profile_on_face, extrude_sketch, add_revolved_profile, add_swept_profile, cut_profile...). The description never states what distinguishes this tool from those siblings — e.g. that it builds a body from an explicit point list rather than an existing sketch or 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?

There is no when-to-use or when-not-to-use guidance, and no alternative is named. With roughly a dozen overlapping extrusion/profile siblings, an agent is left to infer selection entirely from names, and "independent native SOLIDWORKS engine" does not resolve that choice.

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

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

Annotations already declare destructive=true, non-idempotent, and non-readonly, so the safety profile is covered. Beyond that the description only adds a unit convention; 'inspect verified measurements and error evidence' is unsubstantiated marketing text that describes neither the mutation's effect on the model nor failure modes. With 0% schema coverage, the burden is on the description and it is largely unmet.

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, so it reads quickly. The third sentence carries no actionable information and occupies space that could have described the face reference or the point polygon.

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

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

A destructive geometry-creating tool with five parameters, no output schema, and no parameter documentation needs substantially more than a units note. An agent cannot tell from this description what a valid face string looks like or what the tool returns on success.

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 none of the five parameters are described. The unit statement implicitly tells the agent that points_mm and depth_mm are millimetres, but the format of the required 'face' string, the meaning of name, and how corner_radii_mm maps to the point list are left 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 ('Add extruded profile on face'), which is clearer than a bare name restatement. It does not distinguish itself from close siblings such as add_extruded_profile_on_plane or add_boss_on_face, so it stops short of full 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?

No guidance on when to choose this over add_extruded_profile_on_plane, add_extruded_profile, or add_boss_on_face, all of which sit in the same sibling list. No prerequisites, no mention that a valid face reference from list_faces 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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false, and the description does not build on that by explaining what geometry gets consumed or created, whether an existing body is modified, or what happens when merge is toggled. The only added context is the unit convention (mm, degrees, kg) and a vague mention of measurements and error evidence, which is thin for a destructive modeling 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?

Three short sentences with the operation front-loaded, so there is no bloat. However, the second and third sentences read as generic boilerplate that would fit almost any tool in this server rather than targeted 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?

This is a complex destructive geometry operation with 8 undocumented parameters and no output schema, and the description covers none of the details an agent needs, such as plane naming conventions, valid point-array shapes, or what the call returns. The gaps are substantial relative to the tool's 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% across 8 parameters, so the description must carry the burden and it does not. It supplies the unit convention, which does clarify depth_mm, draft_deg, and points_mm, but plane, merge, reverse, corner_radii_mm, and name receive no explanation of expected format or effect.

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

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

The first sentence is essentially the tool name restated ('Add extruded profile on plane'), with only the added qualifier that it runs through the native SOLIDWORKS engine. It never differentiates this tool from the close siblings add_extruded_profile, add_extruded_profile_on_face, or add_revolved_profile, so an agent reading only the description cannot tell which one applies.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative is named despite several near-identical extrusion siblings. The closing sentence 'Inspect verified measurements and error evidence' hints at a post-call workflow but is not actionable selection 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 destructive=true, non-idempotent, and closed-world, so the safety profile is known. The description adds real value with the unit convention (mm/degrees/kg) and the note that results include verified measurements and error evidence, but it never says what the slot actually removes or adds, whether it cuts an existing body, or that repeated calls stack new 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?

Three short sentences, front-loaded with the action, so it is easy to scan. However 'through the independent native SOLIDWORKS engine' is positioning language rather than actionable information, and 'Inspect verified measurements and error evidence' is vague about what is returned.

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

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

A destructive five-parameter geometry mutation with no output schema and no parameter documentation needs more: which document/body the slot targets, whether it is a cut or a boss, and how the two point parameters define the slot. The unit note is the only substantive addition, leaving an agent likely to guess at placement 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 description coverage is 0% across five parameters, so the description carries the burden. It explains that lengths are mm, which anchors start_mm/end_mm/width_mm/depth_mm, but it never clarifies that start_mm and end_mm are 2D 2-element coordinate pairs (centerline endpoints) or what depth means relative to the body. Units alone do not fully compensate for the coverage gap.

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

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

States a specific verb+resource ('add extruded slot') and tells the agent the operation is performed by the native SOLIDWORKS engine rather than a mesh proxy. It does not differentiate from close siblings such as cut_slot, extrude_sketch, or add_extruded_profile, so the agent cannot tell from the description alone which of these to pick.

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

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

No guidance on when to use this versus cut_slot or extract_sketch-style siblings, and no prerequisites (active document, which body/plane the slot is placed on). The only implicit guidance is the trailing hint to inspect measurements and error evidence after the call.

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, non-idempotent and closed-world, so the safety profile is covered. The description adds the unit convention (mm/degrees/kg) and that the result carries verified measurements and error evidence, but never says what existing geometry may be affected or what a failure 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?

Three short sentences with the action front-loaded, so it is not bloated. However, the closing sentence about "verified measurements and error evidence" is opaque and does not translate into actionable information for the caller.

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 destructive geometry-mutating tool with zero parameter documentation and no output schema, so the description must carry a heavy load. It omits point ordering/planarity, the minimum three-point constraint, whether the extrusion adds to or replaces existing bodies, and what errors look like.

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 all three parameters. The unit sentence gives mm context that the _mm suffixes already imply, but nothing explains that points_mm is a list of 2D [x,y] pairs with a minimum of 3 points, or that depth_mm must be strictly positive, or what name controls.

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?

"Add extruded spline" is a specific verb+resource pair, so an agent knows a spline-based extrusion is created. It does not differentiate itself from close siblings such as add_extruded_profile, add_swept_profile, or extrude_sketch, leaving the agent to guess which geometry primitive to choose.

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

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

There is no statement of when to use this tool versus the many sibling profile/loft/sweep/extrude tools, and no preconditions (open document, active part) are given. "Inspect verified measurements and error evidence" hints at post-call behavior but is not usage 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, readOnlyHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds the unit convention (mm, degrees, kg) that governs radius values. It does not, however, say what geometry is consumed or altered, whether edges are re-selected on re-run, or what the engine's error evidence looks like.

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

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

Purpose is front-loaded in a short first sentence, which is good. The remaining two sentences are thin boilerplate that describe general platform conventions rather than anything specific to filleting, so they do not fully earn their 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?

This is a destructive six-parameter geometry mutation with no output schema and no parameter documentation. For that complexity the description is far too sparse: edge selection format, what happens on invalid radii, and the shape of returned measurements are all left to guesswork.

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 six parameters, so the description must carry the load. It only clarifies that lengths are in mm, implicitly covering radius_mm, radii_at_mm and skip_shorter_mm. The most ambiguous parameter, edges (a string defaulting to "all"), plus tangent_propagation and name receive no explanation of accepted syntax or selection semantics.

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

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

"Add fillet" is a specific verb plus resource, so an agent can tell it creates a rounded edge feature. It does not distinguish itself from adjacent siblings such as add_chamfer or add_full_round, so the reader must infer which rounding tool applies.

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 pick this over add_full_round or add_chamfer, no prerequisites (must a part be active? must edges exist?), and no exclusions. "Inspect verified measurements and error evidence" hints at a verification step but never says what conditions cause failure or how to recover.

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 and idempotentHint=false, so the safety profile is known. The description adds the units convention (mm/degrees/kg) and a hint that measurements are verified with error evidence, but it never states what existing geometry is consumed or modified, what happens on failure, or whether the operation requires a selected face from list_faces.

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 units stated up front, so there is little waste. However, 'through the independent native SOLIDWORKS engine' and 'Inspect verified measurements and error evidence' are vague filler that consumes the limited space without conveying actionable meaning.

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 destructive mutation tool with five undocumented parameters, no output schema, and no clarification of return or error behavior. For a geometry-creation call whose correctness depends on how 'face' and the coordinates are supplied, the description leaves the essential calling details 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% across five parameters, so the description must carry the load and does not. It never explains how 'face' is identified (name, index, reference from list_faces) or what the x_mm/y_mm/z_mm triple represents — a point, a direction, or a radius/offset — leaving the required coordinate parameters semantically empty.

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 verb 'add' plus 'full round' names a resource, but 'full round' is domain jargon and the description never says what geometry (a corner fill between faces?) is produced. It also fails to distinguish this from close siblings such as add_fillet and add_chamfer, so an agent cannot tell why it would pick this over 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?

There is no when-to-use guidance: nothing says when a full round is preferred over add_fillet, nor any prerequisite such as an active document, an existing body, or valid face identifiers. The only usable hint is the units convention.

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

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

Annotations already declare destructive=true, idempotent=false and readOnly=false, so the risk profile is covered structurally. The description usefully adds the unit convention (mm, degrees, kg) and hints that the result should be checked for measurements and error evidence, but it never says what geometry is removed, whether a body must exist, or that repeated calls create duplicate holes.

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 with no padding, and the action is front-loaded. The final sentence ("Inspect verified measurements and error evidence") is vague and does not tell the agent concretely what to do or expect, weakening the structure.

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

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

For a destructive mutation with no output schema and zero schema annotation, the definition leaves significant gaps: no return-value expectation beyond a vague hint, no placement semantics, and no disambiguation among the crowded set of hole-creating siblings. The unit statement is a helpful addition but not enough to make it complete.

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

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

Schema description coverage is 0% across four parameters, so the description carries the burden, yet it only confirms that *_mm parameters are in millimetres. It never explains that x_mm/y_mm are the hole centre location on the sketch plane, what "name" identifies, or that diameter must be positive.

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 verb and resource ("Add hole") and names the engine, so the basic action is clear. But it never says what kind of hole (simple through-hole?), where it is placed, or how it differs from the many hole siblings such as add_counterbore_hole, add_hole_on_face, and add_hole_wizard, which the agent must pick between.

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

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

There is no when-to-use guidance at all: no mention of prerequisites (an open part, sketched coordinates), no exclusions, and no routing to alternative hole tools. "Through the independent native SOLIDWORKS engine" hints at an execution backend but not at usage conditions.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the description adds little on the mutation side — it never says what geometry is destroyed, whether the hole is through-all by default, or what permissions/preconditions apply. The unit convention (mm, degrees, kg) and the note to inspect 'verified measurements and error evidence' add modest context, but not enough for a destructive modeling 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?

It is short and front-loaded with the action, which is good, but the middle sentence about the 'independent native SOLIDWORKS engine' is marketing filler that consumes space where parameter guidance should be. No wasted repetition, but low information density.

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

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

For a destructive 8-parameter modeling tool with no output schema and 0% schema coverage, the description is thin — it should at minimum define the face reference and depth semantics. The hints about units and error evidence partially compensate for the missing output 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 0% across 8 parameters, so the description must compensate and does not: it never explains what 'face' expects (a face ID from list_faces? a name?), what null depth_mm means, or what from_edges toggles. Only the unit convention is clarified, which is already implied by the _mm suffixes.

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 verb and resource are clear (add a hole on a face), but the tool sits among close siblings — add_hole, add_counterbore_hole, add_hole_wizard, add_boss_on_face, add_extruded_profile_on_face — and the description does nothing to distinguish it from add_hole or explain what 'on face' uniquely means. An agent cannot choose confidently without opening 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?

There is no when-to-use, when-not-to-use, or alternative-selection guidance. The phrase 'through the independent native SOLIDWORKS engine' describes the backend rather than the usage context, so the agent gets no routing help.

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

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

The annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the agent knows this mutates the model. The description adds nothing beyond that: it does not say what geometry is created or removed, whether it requires a selected face, or what errors look like, and 'Inspect verified measurements and error evidence' is too vague to be actionable.

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 with the action front-loaded, which is structurally reasonable. The final sentence is boilerplate about inspecting evidence and adds no operational value, so the text is not fully earning 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?

This is a destructive, non-idempotent mutation with 10 undocumented parameters and no output schema. The description covers neither parameter semantics, prerequisites, nor the result, so an agent cannot call it confidently without reading the raw schema and 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 description coverage is 0% across 10 parameters, so the description must compensate and largely fails. It only establishes units (mm, degrees, kg), leaving kind, size, face, fit, thread, depth_mm, and name entirely undefined; for example, what values 'kind' and 'size' accept, or how 'face' is referenced, is nowhere stated.

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

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

The description states a specific verb and resource ('Add hole wizard'), so an agent knows a hole feature is being created. However, it does not distinguish this tool from close siblings such as add_hole, add_counterbore_hole, or add_hole_on_face, so selection between them 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?

There is no guidance on when to use this wizard versus the other hole-creation tools, nor any mention of prerequisites such as an active document or an existing face. The only hint is a units convention, which is not usage guidance.

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

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

The annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=false, so the mutation/safety profile is covered. The description adds genuinely new context by fixing units to mm, degrees and kg and by pointing at verification/error evidence afterward, but it never says what the operation creates or overwrites in the model tree (new patterned features? consumes the seed feature?).

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 short and the operation is front-loaded, which is good. But the closing sentence 'Inspect verified measurements and error evidence' is vague boilerplate that does not tell the agent what to do with it, so one of three sentences does not fully 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?

This is a destructive modeling operation with zero schema description coverage and no output schema, which is the case where the description must do the most work. Instead it omits prerequisites, what geometry is produced, how failures surface, and what direction and feature_name accept, leaving the agent under-equipped to call it correctly.

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

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

Schema description coverage is 0%, so the description carries the burden, and it only partially does: 'units are mm' implicitly explains spacing_mm, but count, direction (default '+x', valid axis strings undocumented) and feature_name (which feature to pattern, or null behavior) are never mentioned. Two of the four parameters remain semantically opaque.

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

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

The description states a specific verb+resource ('Add linear pattern'), and the word 'linear' distinguishes it from siblings such as add_circular_pattern and add_mirror without needing their schemas. It does not, however, say what is being patterned or what the result attaches to, so the purpose is clear but shallow.

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

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

There is no when-to-use guidance, no prerequisite (e.g. a selected feature or body must exist), and no routing to alternatives like add_circular_pattern or add_mirror. The agent must infer from the name alone that this replicates an existing feature along a direction.

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

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

Annotations already declare a non-readonly, destructive, non-idempotent write. The description adds unit conventions (mm, degrees, kg) and points at 'verified measurements and error evidence', which is useful context about what the call returns. However, it never says what a failed loft does to the existing model, whether the solid is added to the active part, or what 'verified measurements' concretely means.

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

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

It is short and the action is front-loaded, but 'through the independent native SOLIDWORKS engine' is promotional filler, and 'Inspect verified measurements and error evidence' is vague phrasing that does not clearly tell the agent what to do with the result.

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 destructive modeling operation with a complex nested input schema, no output schema, and no schema descriptions. The description should explain the profile and height inputs and the failure behavior; instead it covers units and a vague verification hint, leaving the hard parts 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% and the schema is deeply nested: profiles_mm accepts either polygons of 2D points or circles with center_mm/diameter_mm, and heights_mm needs at least two values. The description explains none of this. The unit sentence at least confirms mm for the *_mm parameters, but the critical profile-format choice is 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: 'Add lofted solid'. That is clearly distinguishable from most siblings, but it never contrasts itself with 'loft_sketches', which sounds like the closest alternative, so the agent gets no help choosing between the two.

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

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

There is no when-to-use guidance, no prerequisite statement, and no mention of alternatives such as loft_sketches. The agent is left to infer that this is the loft creation tool and when it applies.

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

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

Annotations already declare destructive=true, non-idempotent, non-read-only, so the safety profile is covered. The description adds only the unit convention (mm/degrees/kg) and a vague note about inspecting measurements and error evidence; it says nothing about what state is mutated, whether existing mates are affected, or what mate types are valid. Below the lowered bar set by annotations.

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

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

Three short sentences with the purpose front-loaded, so it is easy to scan. However "independent native SOLIDWORKS engine" is positional filler and "Inspect verified measurements and error evidence" is vague enough to not earn its space given the omitted parameter 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 an 8-parameter, non-idempotent, destructive assembly-mate tool with zero schema documentation and no output schema, the description is far from complete. The most consequential gaps are the valid mate_type values, how faces/components are referenced, and what the flip flag does.

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 8 parameters, so the description must compensate and it largely does not. The unit sentence does clarify that distance_mm and angle_deg are in mm/degrees, which is genuinely useful, but comp_a/comp_b/face_a/face_b naming conventions and especially the unbounded mate_type string (default "coincident", no enum) are left 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?

"Add mate" names a verb and resource, and the addition of "through the independent native SOLIDWORKS engine" situates it as an assembly-constraint operation. But it never says what a mate relates (two components via faces), and it does not distinguish itself from siblings like delete_mate or suppress_mate beyond the verb. Minimum viable.

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

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

There is no when-to-use guidance, no preconditions (e.g. components must be inserted into an active assembly), and no mention of alternatives among the many assembly siblings. The sentence "Inspect verified measurements and error evidence" gestures at post-call verification but does not tell the agent when this tool is the right choice.

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, and non-idempotent, so the safety profile is covered structurally. The description adds useful behavior beyond that: the unit system (mm, degrees, kg) and the promise of verified measurements and error evidence in the response. It still does not explain what the destructive flag means here (e.g., whether the source features are consumed or a new feature is added) 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?

Three short sentences with the operation stated first and the supporting metadata after it; nothing is padded or repeated. The brevity is efficient, though the second and third sentences read as generic boilerplate applicable to many sibling tools.

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 destructive mutation tool with four undocumented parameters and no output schema, yet the description explains none of the parameter semantics or invocation prerequisites. For an agent to call it correctly it needs at minimum to know what form 'plane' takes and what the 'features' array contains.

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

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

Schema description coverage is 0% across four parameters, so the description must compensate and largely fails to. Only the unit for offset_mm is implied by the units sentence; the required 'plane' parameter (a plane name? a reference?) and the 'features' array are left completely unexplained.

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

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

The description states a specific verb and resource (add a mirror feature) and identifies the engine executing it, so an agent can tell what operation is being performed. It does not, however, distinguish this from pattern-style siblings such as add_linear_pattern or add_circular_pattern, nor does it say what is being mirrored (features vs. 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?

There is no when-to-use guidance, no mention of prerequisites such as an active document or a preselected body/feature set, and no alternatives named. The agent must infer invocation conditions entirely from the schema and annotations.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the mutation profile is covered. The description adds genuinely new context — the unit system (mm, degrees, kg) and that verified measurements and error evidence should be inspected — but never explains what a failed or duplicate plane addition does to the model.

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

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

Three short sentences, front-loaded with the action, with no filler or repetition. The second and third sentences read as boilerplate shared across the tool family rather than tool-specific detail, which slightly dilutes the density.

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

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

This is a destructive, non-idempotent mutation tool with five undocumented parameters and no output schema, so the description must do heavy lifting. It covers units and post-call verification but leaves the parameter contract and the effect of the operation on the document unspecified.

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 five parameters, so the description carries the full burden and mostly fails it: 'base', 'name' and especially 'about' are never explained. The only help is indirect — the stated units imply angle_deg is in degrees and offset_mm in millimetres — which is insufficient for the three string parameters.

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

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

The description names a specific verb and resource ('Add plane') and identifies the engine that executes it, so an agent knows this creates a reference plane. It does not distinguish the tool from the many other add_* siblings or say how the plane is defined (base/offset/angle), leaving the geometry model implicit.

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

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

There is no guidance on when to use this versus siblings such as add_sketch, cut_profile_through_plane, or add_extruded_profile_on_plane, and no prerequisites (e.g. an active part document) are stated. 'Inspect verified measurements and error evidence' is post-call advice, not selection guidance.

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

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

The annotations already disclose that this is a destructive, non-idempotent mutation, so the description need not restate that. It adds some context with units and a mention of verified measurements and error evidence, but it does not explain what is destroyed, what verification output is returned, or how failures are reported.

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

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

The first sentence is direct and front-loads the action, and the overall description is short. However, phrases like 'independent native SOLIDWORKS engine' are implementation detail, and the closing sentence about inspecting measurements and error evidence is vague and not actionable.

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

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

For a five-parameter geometry-creation tool with no output schema and no parameter descriptions, the definition is materially incomplete. It gives units but omits the meaning of the required profile array, axis behavior, angle limits, and what the agent should expect to inspect after the call.

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

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

With 0% schema description coverage across five parameters, the description provides only unit information (mm, degrees, kg). It does not explain that profile_mm is an array of 2D points with at least three points, what axis_mm represents, or how angle_deg and corner_radii_mm are interpreted.

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

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

The description states a specific verb and resource: 'Add revolved profile,' which clearly identifies the operation. It does not explicitly distinguish this from sibling profile tools such as add_extruded_profile or add_swept_profile, so it falls short of a 5.

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

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

There is no explicit guidance on when to choose a revolved profile versus an extruded, swept, or lofted profile. Prerequisites such as whether a sketch or axis is required are also absent.

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=true and idempotentHint=false, so the mutation risk is covered structurally. The description adds real value with the unit convention (mm, degrees, kg) and the note to inspect verified measurements and error evidence, which is the only hint at return content given there is no output schema. It still omits what the operation requires (an open part, a valid sketch/plane reference) and 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?

Three short sentences with the action front-loaded and no filler. Minor waste: "degrees and kg" are irrelevant to a tool with no angular or mass parameters.

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

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

This is a destructive, 5-required-parameter geometry mutation with zero schema documentation and no output schema, so the description should explain the coordinate/vector model and result reporting. Instead it offers only units and a vague pointer to "verified measurements and error evidence," leaving an agent unable to construct a valid call with confidence.

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 6 parameters, so the description carries the full burden and largely fails. It clarifies that lengths are in mm (matching the _mm suffixes) but leaves the meaning of start_mm, end_mm and toward_mm — each a 2-element array — completely unexplained: are they 2D points, direction vectors, or sketch coordinates? The non-obvious z_mm and thickness_mm roles are also unaddressed.

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

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

"Add rib" gives a verb and a resource, and the phrase "through the independent native SOLIDWORKS engine" identifies the execution backend. However, it never says what geometric rib is being created (a thin wall along a path between two points, extruded toward a direction with a given thickness), so an agent cannot distinguish it from siblings like add_extruded_profile or add_boss_on_face beyond the word "rib".

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

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

There is no when-to-use guidance, no prerequisites, and no mention of any alternative among the ~80 siblings. The only implied usage is that it adds a rib to an existing part, which the agent must infer.

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, and idempotentHint=false, so the safety profile is covered structurally. The description adds two pieces of real context beyond that: the unit convention (mm, degrees, kg) and the fact that verified measurements and error evidence are surfaced for inspection. It still omits which body is modified and whether the operation is reversible or absorbs the original solid.

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

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

Three short sentences, front-loaded with the operation, which is good. However, "through the independent native SOLIDWORKS engine" is promotional filler and "Inspect verified measurements and error evidence" is too vague to earn its place without explaining what is returned.

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 destructive mutation with two parameters at 0% schema coverage and no output schema, which sets a high bar. The description leaves the target body, the effect of open_face, failure modes, and the nature of the "verified measurements" unaddressed, so an agent cannot call it confidently from the description alone.

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

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

Schema description coverage is 0%, so the description carries the full burden. It only establishes that thickness_mm is in millimetres; it says nothing about the meaning or accepted values of open_face (defaulting to "+z"), which faces can be opened, or the exclusiveMinimum constraint on thickness.

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 shell") and identifies the engine, but it never says what a shell operation actually produces (hollowing an existing solid to a wall thickness) or which body it applies to. It is not distinguishable from the many other add_* feature tools beyond the word "shell".

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 such as cut_profile, cut_offset_pocket, or cut_slot, all of which also remove material. No prerequisites are stated either, such as requiring an existing solid body or an active document.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the mutation profile is covered structurally. The description adds two genuinely useful behavioral facts: the unit convention (mm, degrees, kg) for all public geometry values, and that the result exposes verified measurements plus error evidence. It still omits what gets modified or destroyed (does it replace an existing sketch?), whether a document must be active, and how failures are reported.

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, so nothing is bloated, but the opening clause about the "independent native SOLIDWORKS engine" is filler that consumes the most prominent position. The closing sentence about inspecting measurements is vague rather than actionable, so the space is not well spent.

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 destructive, geometrically complex tool with three required parameters, a nested segment union type, 0% schema documentation, and no output schema. The description covers units only and leaves an agent unable to construct a valid segments payload or plane reference without trial and error.

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 four parameters, including a deeply nested segments array with oneOf line/arc/spline branches plus center, tangent, and through fields that carry no documentation at all. The description only supplies the mm unit convention, which partially explains start_mm and coordinate arrays but leaves plane format, segment geometry encoding, and the optional name completely 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?

"Add sketch" gives a verb and a resource, but the description never says what a sketch is composed of here (a plane, a start point in mm, and a list of line/arc/spline segments), nor how it differs from siblings like read_sketch, extrude_sketch, cut_sketch, or add_extruded_spline. The phrase "independent native SOLIDWORKS engine" describes the backend rather than the action, so an agent gets only a vague sense of the 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?

There is no guidance on when to use this versus extrude_sketch, cut_sketch, add_extruded_profile, or add_extruded_spline, and no prerequisites such as needing an open document, an active part, or a valid plane reference. The agent must infer everything from the name and schema.

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, and non-idempotent, so safety is covered structurally. Beyond that the description adds only unit conventions; it never says a feature is appended to the active part, whether repeated calls stack duplicate pipes, or what 'verified measurements and error evidence' concretely returns. For a destructive mutation with no output schema, that 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?

Three short sentences, front-loaded with the operation and with no padding. The engine-backend clause is the only low-value sentence, but overall the definition is tight and easy to scan.

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?

Units and a verification instruction give an agent something to work with, but for a 5-parameter destructive geometry tool with no output schema and zero schema descriptions, the definition omits too much about path format, degenerate cases, and error semantics to be self-sufficient.

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 5 parameters, so the description must carry the burden and largely does not. It clarifies that geometry is in mm/degrees/kg, which helps path_mm, diameter_mm, and bend_radius_mm, but says nothing about path_mm being a list of 2D points with at least two entries, what bend_radius_mm=0 means, or what smooth toggles.

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 verb+resource pair 'Add swept pipe' is concrete and tells the agent a solid feature is created. But there is no differentiation from near-identical siblings such as add_swept_profile, swept_region, or add_thread, so an agent cannot tell from the description which sweep-family tool applies. The trailing phrase about the 'independent native SOLIDWORKS engine' describes the backend, not the 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?

There is no when-to-use guidance, no prerequisite (active document, existing sketch or path), and no mention of alternatives among the many add_* siblings. The only actionable hint is 'Inspect verified measurements and error evidence,' which describes post-call verification rather than tool 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 already declare destructiveHint=true, readOnlyHint=false, and non-idempotent behavior, so safety is covered structurally. The description adds useful context (unit system in mm/degrees/kg and that verified measurements plus error evidence are surfaced for inspection), but it does not say what geometry is created or destroyed, whether the operation is reversible, or what the evidence looks like.

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 followed by unit conventions and the inspection hint. No filler, though the second and third sentences read as boilerplate that could be tightened.

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 destructive geometry mutation with nested point arrays, no output schema, and zero schema description coverage, yet the description leaves the parameter structure and the returned verification/error evidence entirely unexplained. For a tool of this complexity it does far too little to prepare the agent for a correct call.

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

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

Schema description coverage is 0% across five parameters, so the description must compensate, and it does partially by stating that public geometry units are mm, which annotates profile_mm, path_mm, bend_radius_mm, and corner_radii_mm. It still says nothing about the point-array structure (3+ profile points, 2+ path points), the meaning of bend_radius defaulting to 0, or that corner_radii accepts a scalar or per-corner array.

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 ("Add swept profile") and signals that this builds geometry natively in SOLIDWORKS via the profile/path pair. It does not differentiate from the obvious sibling add_swept_pipe, so an agent must infer that distinction, but the core purpose is unambiguous.

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

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

There is no guidance on when to choose this over add_swept_pipe, add_lofted_solid, add_revolved_profile, or the sketch-based extrude/sweep tools. Nothing states prerequisites such as needing closed profile geometry or how it differs from the pipe variant.

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 and non-idempotence, so safety is covered structurally. The description adds genuinely useful context: the public unit convention (mm, degrees, kg) and that results come with verified measurements and error evidence. It still does not say what the operation destroys or how the text is applied to the face.

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 with the operation stated first, followed by unit convention and verification behaviour. The final sentence about inspecting measurements and error evidence is slightly vague but not wasteful enough to penalise heavily.

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 10-parameter destructive mutation with no output schema and no parameter documentation, and the description does not address the most critical ambiguity: what identifies a 'face'. Combined with silence on emboss-vs-engrave semantics and return format, it is under-specified for the tool's 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% across 10 parameters, so the description must carry the load. It does clarify that linear inputs are millimetres, which helps x_mm/y_mm/z_mm/height_mm/depth_mm, but leaves 'face' (a bare string with no format guidance), 'emboss', 'font' and 'name' 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 ('Add text on face'), which an agent can distinguish from siblings like add_boss_on_face or add_hole_on_face that operate on the same 'on face' target. It does not explicitly name those alternatives, so differentiation is inferred rather than stated.

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

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

Usage is implied by the name and the unit convention, but there is no explicit when-to-use guidance, no exclusions versus the other *_on_face tools, and no statement of prerequisites (e.g., an active document or a valid face reference).

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

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

Annotations already declare this is a mutating, destructive, non-idempotent, closed-world operation, so the safety profile is covered. The description adds marginally by naming the engine and promising "verified measurements and error evidence," hinting at post-operation validation. What exactly is modified or destroyed, and what permissions/preconditions are needed, is still unstated.

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 engine, then units, then verification. Nothing is padded, though "Inspect verified measurements and error evidence" is slightly opaque phrasing that could be tightened into a concrete statement of what is returned.

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

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

A 7-parameter destructive geometry-creation tool with no output schema and zero schema descriptions needs substantially more: the thread size vocabulary, the meaning of internal/length, and placement semantics are all missing. The units note is the only substantive help.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it only partially delivers: it clarifies that x_mm/y_mm/z_mm/length_mm are millimetres. The critical 'size' parameter (thread designation format such as "M6x1.0") and the 'internal' boolean (internal vs external thread) are left unexplained, as is whether coordinates are a start point or a face anchor.

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?

"Add thread" gives a specific verb plus the feature type, and "through the independent native SOLIDWORKS engine" signals that this creates real model geometry rather than a mock. It is reasonably distinguishable from generic siblings like add_box or add_hole, though it never says whether the thread is cosmetic/feature-based or whether it must attach to an existing face or hole.

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

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

There is no when-to-use guidance at all: nothing says whether this should follow add_hole, add_hole_wizard, or add_counterbore_hole, nor whether a body or plane must already exist. The only implied context is the units statement, which is not a usage 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds genuine context beyond that — the 'independent native SOLIDWORKS engine' backing and the unit conventions (mm, degrees, kg) — but says nothing about cost, runtime, or whether a rebuild is required before checking.

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 with the action front-loaded, so it is far from bloated. However, 'Inspect verified measurements and error evidence' is phrased as an instruction to the caller rather than a description of behaviour, and the engine-provenance sentence is marketing-adjacent 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?

There is no output schema, so the description carries the burden of explaining what comes back — it only gestures at 'verified measurements and error evidence' without saying whether that is an interference list, a clearance value, or an error log. Combined with the missing scope statement, an agent cannot predict the result shape before calling.

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 and the baseline is 4. The unit note is a small bonus for interpreting results rather than inputs.

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

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

The verb+resource ('Check interference') is identifiable, but the scope is left unspecified — the description never says whether it checks the active assembly, all bodies, or a selection, and with zero parameters that ambiguity matters. It also offers no differentiation from near-neighbours such as check_motion, check_printability, or measure_distance.

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

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

There is no when-to-use statement, no precondition (e.g. an assembly must be active), and no mention of alternatives. The agent must infer from the name alone whether this is the right inspection tool among the many verification siblings.

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 frames the tool purely as inspection ('Check', 'Inspect verified measurements and error evidence'), implying a read operation, while annotations declare readOnlyHint=false and destructiveHint=true. With no mention of mutation, side effects, prerequisites, or what may be altered in the model, the framing actively misleads about the tool's risk profile.

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 with no padding and the engine claim front-loaded, so it is structurally clean. However, the brevity is under-specification rather than efficiency — the units sentence consumes space that the undefined purpose and parameters needed.

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, non-idempotent tool with a complex nested input schema and no output schema, the description omits what is modified, what 'error evidence' is returned, and how results are shaped. It also promises an 'inspect' result without any return-value guidance, leaving the agent unable to predict 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 description coverage is 0% across three parameters, so the description must compensate and does not: it never explains dimension_name, the nested 'values' array, or what the 'distances' string-pairs mean. The unit note (mm, degrees, kg) is the only added meaning and it is generic rather than per-parameter.

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

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

The verb 'check' plus resource 'motion' is stated, but 'motion' is never defined (motion study? kinematic travel? interference over a dimension sweep?), and the description never distinguishes this from siblings like check_interference, measure_distance, or get_mass_properties. The tie-in to dimension_name/values is left entirely implicit, so an agent cannot tell from the text what is actually being checked.

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

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

There is no when-to-use guidance, no exclusions, and no named alternative among the many check_* and measure_* siblings. The only quasi-guidance is the phrase 'independent native SOLIDWORKS engine', which hints at an engine choice but never says what the alternative would be or when to prefer it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds only that the engine is 'independent native SOLIDWORKS' and that results include 'verified measurements and error evidence' — it never says what a report contains, whether analysis can be slow, or what happens on failure. The value added beyond annotations is thin.

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

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

Three short sentences with no padding, but 'through the independent native SOLIDWORKS engine' is promotional wording that displaces information an agent actually needs, and the units sentence is oddly placed before any parameter explanation.

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 must convey the shape of results — it gestures at 'verified measurements and error evidence' but not the fields or meaning. Combined with completely undocumented parameters and an unspecified check set, the definition is under-specified for a geometry analysis 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% across three parameters, so the description carries the full burden — and it covers almost none of it. Stating 'public geometry units are mm, degrees and kg' does clarify the units of min_wall_mm and overhang_deg, but the 'up' parameter (build orientation, default '+z') and the semantics of 'min_wall' or 'overhang' thresholds are never explained.

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

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

The description states a specific verb and resource ('Check printability') and names an engine, but it never says what printability checks are performed (wall thickness, overhang, orientation) or how this differs from the closely related sibling check_interference. An agent knows the general goal but not the concrete analysis performed.

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

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

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites such as a loaded part or a mesh, and no pointer to alternatives among the many sibling tools. The agent must infer everything about 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 already flag destructiveHint=true and non-idempotent, so the agent knows this is a lossy mutation. The description adds nothing about what is destroyed, that unsaved edits are discarded, or whether the document can be reopened. Instead it talks about units and measurements, which carry no behavioral weight for a close 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?

Three sentences, two of which are boilerplate about units and inspection that do not apply to closing a part. The relevant information (one verb) is a fraction of the text, and the padding obscures rather than front-loads the purpose.

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

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

For a destructive, non-idempotent document operation with an undocumented boolean parameter and no output schema, the description should explain the save flag's effect on unsaved changes. It omits the single thing an agent needs to call this safely, and instead supplies irrelevant unit information.

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

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

There is one parameter (save, default false) with 0% schema description coverage, and the description never mentions it. The description must compensate for this gap since the schema offers no explanation of what save=true does, but it does not.

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?

"Close part" names a specific verb and resource, so the core action is identifiable. However, the following sentences about units (mm/degrees/kg) and inspecting "verified measurements and error evidence" are unrelated to closing a document and actively muddy what the tool does. There is no differentiation from adjacent document-lifecycle siblings such as save_part or open_part.

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

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

The description never says when to close a part, whether save_part should be called first, or what happens to unsaved changes. No alternative or prerequisite is mentioned despite multiple document-lifecycle siblings existing.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds useful unit conventions and the mention of error evidence, but it does not disclose the key destructive consequence for this operation: that source bodies are consumed/merged, nor any permission or document-state requirement.

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 with the purpose front-loaded, so it is not padded. But the closing sentence about inspecting measurements and error evidence is vague and reads as boilerplate rather than actionable 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?

For a destructive, non-idempotent modeling operation with full schema opacity and no output schema, the description is far too thin: it does not define the operation modes, the role of `main` versus `tools`, or what a successful result contains.

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

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

Schema description coverage is 0% across 4 parameters, so the description carries the entire burden of explaining `operation`, `main`, `tools`, and `name`. It mentions none of them, and notably gives no valid values for the required, enum-less `operation` string.

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?

"Combine bodies" is a clear verb+resource pair and is distinguishable from the nearest sibling, split_body. However, the description never says what kind of combine (boolean add/subtract/intersect) is meant, even though the required `operation` parameter implies meaningful variation, leaving the actual capability ambiguous.

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

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

There is no statement of when to use this versus alternatives such as split_body, add_lofted_solid, or the profile/extrude family. No prerequisites (open document, existing bodies) or exclusions are given.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful context that public geometry units are mm, degrees, and kg and that results include 'verified measurements and error evidence,' but it does not explain tolerances, failure behavior, or the comparison method.

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 brief and free of obvious filler, with the core comparison concept front-loaded. Its short sentences are easy to scan, though the middle units sentence is somewhat disconnected from the action.

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

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

For a five-parameter comparison tool with no output schema and no parameter descriptions, the definition is materially incomplete. It mentions units and error evidence but leaves input semantics, comparison behavior, and return structure unspecified.

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 description explains none of the five parameters. It does not clarify what 'path' points to, how 'axis' is interpreted, what 'heights_mm' means, or how 'frame' and 'offset_mm' affect the comparison.

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 largely restates the tool name: 'Compare with mesh.' It adds mechanism ('independent native SOLIDWORKS engine') and units, but never states what is being compared to the mesh or what a comparison produces, leaving the core purpose ambiguous.

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 siblings such as pro_inspect_stl, pro_verify_volume, or check_interference, or any prerequisites for the input mesh. Usage must be inferred entirely from the 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, readOnlyHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered. The description adds two useful pieces beyond that — it runs in the native SOLIDWORKS engine and it returns verified measurements plus error evidence — but says nothing about what geometry is destroyed, whether the operation is undoable, or what preconditions (valid face, closed body) must hold.

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-loads the action, which is good. But "through the independent native SOLIDWORKS engine" is engine-internal jargon that adds no decision value, and "Inspect verified measurements and error evidence" is a vague directive rather than a concrete statement of return contents.

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

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

A destructive CAD mutation with 5 required untitled parameters, no output schema, and no schema descriptions leaves an agent guessing at the most consequential details. The description at least pins down units and signals that measurements and errors come back, but it is far short of what a 7-parameter destructive geometry tool needs.

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 7 parameters, so the description must carry the burden and largely fails. It only implies that _mm parameters are millimetres; it never explains what `face` expects (a face ID from list_faces?), what `rim_mm` measures, how `depth_mm` defaulting to null is interpreted, or what the "offset" in offset pocket refers to.

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 ("Cut offset pocket"), which clearly separates it from generic feature tools like add_fillet or set_dimension. However, it never distinguishes it from the many closely related cut tools in the sibling list (cut_profile, cut_profile_on_face, cut_profile_through_plane, cut_slot), nor does it explain what makes a pocket "offset".

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

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

There is no when-to-use guidance at all: no condition telling the agent to prefer this over cut_profile, cut_profile_on_face, cut_slot, or cut_profile_through_plane. The only contextual statement is about unit conventions, which is not usage 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, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. Beyond that the description adds only the unit convention and a vague promise to "inspect verified measurements and error evidence"; it never says what geometry is removed, whether it requires a selected face or body, or what failure modes look like.

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?

At three short sentences it is not bloated and the verb is front-loaded. But the middle sentences are vague filler ("independent native SOLIDWORKS engine", "error evidence") that consume space without adding actionable 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?

This is a destructive, six-parameter mutation tool with no output schema and zero schema description coverage, so the description carries nearly the whole burden. It leaves the agent without the information needed to construct a valid cut: no polygon interpretation, no depth/plane semantics, no context requirements.

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 six parameters, so the description must carry the meaning, and it supplies only units (mm, degrees, kg). It never explains that points_mm is a minimum-3-vertex 2D polygon, what about_mm anchors, how depth_mm relates to the profile plane, or how corner_radii_mm applies per-corner.

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 ("Cut profile"), which tells the agent this removes material using a profile. However, it does not distinguish the tool from close siblings such as cut_profile_through_plane, cut_profile_on_face, cut_sketch, or cut_offset_pocket, nor does it clarify that points_mm defines a closed polygon extruded through the 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?

There is no when-to-use guidance at all: no statement of prerequisites (an open document/part, an existing body), no conditions for choosing this over the several cut_* and extrude_* siblings, and no exclusions. The only routing signal is the word "Cut" in the 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, readOnlyHint=false and non-idempotent, so the safety profile is known. The description adds only the unit convention and a vague "inspect verified measurements and error evidence" line; it never says that material is removed from the body, what happens on failure, or whether an active document is required.

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 with no padding, which is structurally fine, but they are front-loaded with engine branding and end with an uninformative sentence about inspecting measurements and error evidence. Brevity here reflects under-specification rather than discipline.

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 destructive, multi-parameter CAD modeling operation with no output schema and zero schema-level parameter documentation, yet the description is three generic sentences. An agent cannot determine valid face references, point-list semantics, or depth defaults from this definition.

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 five parameters, so the description carries the full burden and mostly fails. It gives the unit convention (mm/degrees/kg), but leaves the meaning of `face` (face ID? selector string?), the `points_mm` polygon requirement (min 3 points, 3 coordinates each), `depth_mm`, and `corner_radii_mm` (scalar vs. per-corner list) 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?

"Cut profile on face" names a verb and a resource, but it largely restates the tool name and does not distinguish it from close siblings such as cut_profile, cut_sketch, cut_profile_through_plane, or cut_offset_pocket. The added clause about the "independent native SOLIDWORKS engine" is branding rather than a clarifying scope 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 use this tool versus cut_profile, cut_sketch, or cut_profile_through_plane, and no prerequisites (e.g. an open part, an existing face reference). The agent must infer the use case entirely from the 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, idempotentHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds modest extra context: public geometry units (mm/degrees/kg) and a note that verified measurements and error evidence can be inspected. It does not say what geometry is removed, whether the cut is reversible, or what error conditions look like.

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

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

It is short and front-loads the operation, which is good, but two of the three sentences are generic boilerplate (engine identity, units, "inspect verified measurements") that do not help an agent invoke this specific tool. Space that could describe the plane or point semantics is spent on boilerplate instead.

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

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

A destructive six-parameter modeling operation with no output schema and zero schema description coverage needs far more: what plane accepts, whether points_mm are (x,y) or (x,y,z), what keep_inside toggles, and what the cut produces. The description supplies none of this and only gestures at verification output.

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 six parameters, so the description must carry the burden and does not. It explains only the unit convention (mm) implied by the _mm suffixes; plane (a string with no documented format), points_mm (2D vs 3D point list), keep_inside, depth_mm and corner_radii_mm are left entirely undefined.

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

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

The first sentence essentially restates the tool name ("Cut profile through plane") without explaining what is being cut or what the plane does, and adds only engine boilerplate ("independent native SOLIDWORKS engine"). It never distinguishes this from close siblings such as cut_profile, cut_profile_on_face, cut_offset_pocket, or cut_slot, so an agent cannot tell which cut variant to pick.

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

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

No when-to-use guidance, no prerequisites (e.g. must a part document be open or active?), and no exclusions. With four or more sibling cut tools in the list, the absence of any routing hint is a real gap; the only implicit cue is the tool name itself.

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, idempotentHint=false, and openWorldHint=false, so the description does not need to restate mutation. What it fails to say is more important: whether the cut consumes or preserves the source sketch, what happens when depth_mm is null versus set, or what 'error evidence' looks like. 'Independent native SOLIDWORKS engine' is marketing framing rather than behavioral information.

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 with the core action front-loaded, so it is not bloated. But the third sentence ('Inspect verified measurements and error evidence') is vague filler that doesn't tell the agent what to look at or 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?

This is a destructive mutation with no output schema, zero parameter documentation, and no explanation of what gets destroyed or how to verify success. The description should compensate for the bare schema and does not – an agent has to guess at reverse, null depth, and the return shape.

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 for four parameters and covers almost none of them. It does establish that depth_mm is in millimetres and that units are mm/degrees/kg, which adds some meaning, but 'sketch', 'reverse', and 'name' are entirely unexplained – notably that null depth likely means through-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 names a verb and resource ('Cut sketch'), but the sibling list contains several closely related cut tools (cut_profile, cut_profile_through_plane, cut_profile_on_face, cut_offset_pocket, cut_slot) and the description offers nothing to distinguish this one. An agent cannot tell from the text whether this is a through-all cut, a depth cut, or a profile cut.

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

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

There is no when-to-use or when-not-to-use guidance at all. With five near-identical cut siblings, the absence of routing guidance is a real gap – nothing indicates whether this should be preferred over cut_profile or extrude_sketch.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the safety profile is covered. The description adds almost nothing beyond that: it does not say what geometry is removed, whether depth_mm=null means a through-cut, or whether re-invocation creates a duplicate slot. The "Inspect verified measurements and error evidence" sentence hints at a return payload that has no output schema to describe it, but leaves the content undefined.

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 operation, which is good. However, the third sentence is vague promotional framing about inspecting measurements and error evidence rather than actionable information, so words are spent without adding usable content.

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

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

A destructive, 7-parameter geometry operation with 0% schema coverage and no output schema demands far more than this. Missing are the required target body/context, the through-vs-blind depth behavior, coordinate reference, and what the returned 'measurements' and 'error evidence' actually look like.

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 7 parameters, so the description carries the full burden and fails to meet it. Only the unit convention (mm, degrees) is clarified; the meaning of x_mm/y_mm placement, angle_deg direction, and especially the nullable depth_mm default (likely through-all) is undocumented anywhere.

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?

"Cut slot" is a specific verb plus resource, but the description never distinguishes it from close siblings such as add_extruded_slot, cut_profile, or cut_offset_pocket. An agent cannot tell from the text whether this removes material from an existing body or creates a slot feature on a sketch/face, which is exactly the distinction those siblings embody.

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

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

There is no when-to-use guidance and no mention of alternatives or prerequisites (e.g., an active document, an existing body or face). The phrase "through the independent native SOLIDWORKS engine" implies context but does not tell the agent when to pick this over add_extruded_slot.

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, and idempotentHint=false, so the safety profile is covered. Beyond that, the description adds only vague marketing-style phrasing ("independent native SOLIDWORKS engine", "Inspect verified measurements and error evidence") without stating what happens to mated/dependent geometry, whether the deletion is reversible, or what the response contains.

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 opening clause is well front-loaded, but the remaining two sentences are boilerplate: unit conventions (mm/degrees/kg) are irrelevant to a deletion, and "inspect verified measurements and error evidence" is unfalsifiable filler that consumes attention without informing the call.

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 mutation with one fully undocumented parameter and no output schema, the description omits the essential context: valid identifier forms, behavior on failure, and impact on assemblies or mates referencing the component. An agent cannot call this correctly without trial and error.

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

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

Schema description coverage is 0% and the single required parameter "component" is a bare string with no enum or format. The description says nothing about how a component is identified (name, index, path, or handle), so it fails to compensate for the coverage gap.

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

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

"Delete component" is a specific verb+resource pair that names exactly the operation performed. It does not, however, distinguish this from nearby siblings such as delete_feature, delete_mate, or delete_equation, nor explain what constitutes a 'component' in this domain.

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

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

There is no guidance on when to use this versus delete_feature or replace_component, no prerequisites, and no warning about irreversible removal of a component from a document. The agent must infer all usage conditions from the name alone.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the safety profile is covered without the description. The description adds nothing behavioral beyond that: it does not say whether deletion is permanent, what happens if the equation name is not found, or whether dependents are affected. The two boilerplate sentences about units and 'verified measurements' are irrelevant to a delete operation and read like copy-paste from a geometry 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 operative information is one sentence; the other two are unrelated boilerplate (geometry units, measurement inspection) that cannot apply to a deletion that returns nothing. Signal-to-noise is poor and the irrelevant content comes after the useful part, so an agent may waste attention parsing it.

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, non-idempotent, single-parameter mutation with no output schema, the description should identify the parameter format and the consequences of the call. Neither is present, and the units/measurement sentences actively mislead about what this tool does. What remains is essentially just the name restated.

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

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

Schema description coverage is 0% and the single required parameter 'equation' is an untyped string with no explanation. The description never clarifies whether this is an equation name, an index, or a full expression string, which is the one thing an agent must know to call this correctly. With no schema documentation to fall back on, the description fails to compensate.

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

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

The first sentence states a specific verb (Delete) and resource (equation), which is enough to distinguish it from set_equations and list_equations among the siblings. The remaining sentences (units, 'verified measurements and error evidence') add no distinguishing information and muddy an otherwise clear purpose.

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 set_equations (which could presumably overwrite) or delete_feature. No prerequisites, no confirmation that the equation must already exist, and no note that the caller should list_equations first to obtain a valid identifier.

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 and idempotentHint=false, so the safety profile is covered structurally. The description adds little beyond that: the 'independent native SOLIDWORKS engine' phrasing is opaque, the units sentence is irrelevant to a deletion, and it never says whether deletion cascades to children or equations or is undoable. 'Inspect verified measurements and error evidence' is vague boilerplate that does not tell the agent what to check.

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

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

It is short and front-loads the purpose, but two of the three sentences do not earn their place: the unit convention is irrelevant to deleting a feature, and the 'verified measurements and error evidence' line is too vague to be actionable.

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 mutation with four undocumented parameters and no output schema, the description should explain the cascade flags and the dry-run behavior. Instead the agent must guess what with_equations and with_children do before performing an irreversible 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?

All four parameters have 0% schema description coverage, and the description mentions none of them. The meaning of dry_run, with_children and with_equations is left entirely unexplained, which is critical for a destructive operation where the difference between a preview and a cascading permanent delete matters.

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 feature'), so the core action is unambiguous. It does not differentiate itself from obvious siblings such as suppress_feature, delete_component, delete_equation or delete_mate, and the agent must infer the boundary from the name 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?

There is no guidance on when to delete versus suppress a feature, no prerequisites, and no explanation of when the dry_run flag should be used before committing a destructive change. The only routing information an agent gets is the tool name itself.

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 and idempotentHint=false, so the safety profile is known. The description adds nothing beyond that: it doesn't say whether the deletion is reversible, what happens to components the mate constrained, or what the vague phrase "error evidence" refers to. The units sentence (mm, degrees, kg) is behaviorally irrelevant to a delete 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?

Only the first sentence earns its place. The subsequent sentences about public geometry units and inspecting measurements appear to be generic boilerplate that is not actionable for a delete operation, and they push the useful content to the front without follow-through.

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 destructive mutation tool with a required, undocumented parameter and no output schema. An agent lacks the information needed to identify the mate to delete or to anticipate the effect on assembly constraints, so the definition is not complete enough for safe 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 required parameter is bare `name: string`. The description never clarifies whether this is a mate name, an ID, a feature name, or a component pair identifier, nor the expected format or where such a name can be discovered. With one undocumented parameter, the description needed to compensate and did not.

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

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

The first sentence does state a specific verb and resource ("Delete mate"), so the core action is identifiable. However, it offers no differentiation from closely related siblings such as suppress_mate or delete_component, and the two trailing sentences about units and "verified measurements" are unrelated to a deletion and dilute the stated purpose.

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 delete a mate versus suppressing it (suppress_mate) or when a mate disappears implicitly through delete_component. No prerequisites, no ordering considerations (e.g., must the assembly be active), and no statement of 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?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=false, so the write-and-risk profile is largely covered by structured data. The description adds real context not present in annotations: public geometry units are mm, degrees and kg, and the call surfaces "verified measurements and error evidence" rather than a bare success flag. It still omits that the call writes a file to a path, what refusal looks like on an existing target, and any rate or engine-session constraints, so it only marginally clears the lowered bar.

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 with no filler, and the engine statement is front-loaded. However, the closing sentence "Inspect verified measurements and error evidence" is an imperative fragment with no object and reads as direction to the reader rather than description of tool output.

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

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

A destructive, seven-parameter export with no output schema and 14% schema coverage needs the description to carry a lot, and it carries very little: no supported formats, no explanation of the fine/default quality knobs, no description of the evidence returned. The units disclosure is the one substantive contribution. An agent could invoke it but could not predict its side effects or choose correct parameter values.

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 14%: only overwrite is documented, and that documentation lives in the schema, not the description. The units sentence usefully pins down angle_deg (degrees) and deviation_mm (mm), but the required path parameter is never explained as an output destination, and quality, file_format and per_component are left with no meaning in either place.

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?

"Export through the independent native SOLIDWORKS engine" names the verb but never states what is exported (part, assembly, sketch, mesh) or to what destination. Siblings save_part, save_assembly, screenshot, make_drawing and pro_visualize_export all overlap with "export", and nothing in the description separates this tool from them. The "independent native SOLIDWORKS engine" phrasing is identity marketing rather than scope.

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

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

There is no statement of when to choose this over save_part/save_assembly or the pro_visualize_export family. No prerequisites, no mention of what an agent must have open beforehand, and no when-not guidance despite a crowded sibling set of overlapping save/export 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so the mutation risk is known. The description adds genuinely useful context by fixing the unit system (mm, degrees, kg) and noting that verified measurements and error evidence are returned. It still omits what is actually modified (feature/body creation), whether it adds material versus removes it, and how failures surface.

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 with the action front-loaded and no padding. The closing sentence about inspecting measurements is vague, but the overall structure is tight.

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, five-parameter mutation tool with no output schema and zero schema descriptions, the definition is thin. It should at minimum explain the sketch reference, the depth-versus-up_to choice, and the direction flag.

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 five parameters, so the description carries the full burden and largely fails it. Only the unit hint implicitly clarifies that depth_mm is in millimetres; nothing explains the relationship between depth_mm and up_to, what values up_to accepts, what 'reverse' flips, or what the 'sketch' string should reference.

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 ('Extrude sketch'), so the core action is unambiguous. It does not, however, differentiate itself from close siblings such as add_extruded_profile, loft_sketches, or cut_sketch, which an agent must choose between.

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 add_extruded_profile or cut_sketch, nor any stated prerequisite that a sketch must already exist. The agent is left to infer usage entirely.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds useful context the annotations do not: output units (mm, degrees, kg), that it runs through an 'independent native SOLIDWORKS engine', and that results come with error evidence. It does not describe shape of the returned data or failure modes in any detail.

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

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

Three short sentences, front-loaded with the core action. 'Through the independent native SOLIDWORKS engine' is somewhat promotional filler, but nothing is redundant or padded.

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

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

With no output schema, the description carries the burden of explaining return values; it names units and mentions 'verified measurements and error evidence' but never says what a bounding box result actually contains (dimensions, corner coordinates, per-body vs whole-assembly). For a zero-parameter tool this is adequate but leaves a real gap for an agent trying to interpret the response.

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 to disambiguate and the baseline is a 4. The unit statement applies to output rather than inputs, but it is a helpful convention note.

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: 'Get assembly bounding box'. The word 'assembly' distinguishes it from the sibling get_bounding_box, though the description never explicitly names that sibling or clarifies the scope 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 explicit guidance on when to use this instead of get_bounding_box, or on any prerequisites (e.g., an active/open assembly). 'Inspect verified measurements and error evidence' hints at a verification workflow but does not tell the agent when to choose this tool.

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

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

Annotations already fully declare the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's burden is lower. It adds useful context — public units are mm/degrees/kg and the result carries verified measurements plus error evidence — but 'independent native SOLIDWORKS engine' is unexplained and no output shape is described despite there being 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?

Three short sentences with the core action front-loaded and no padding. The middle phrase about the 'independent native SOLIDWORKS engine' is vague marketing language that does not 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?

For a zero-parameter, read-only tool this is close to adequate, but with no output schema the description should say what the bounding box is relative to (coordinate frame, active document, part vs assembly) and roughly what the response contains. 'Verified measurements and error evidence' gestures at this without specifying 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 and the baseline is 4. The stated unit conventions (mm, degrees, kg) are still helpful for interpreting the result even though they are not parameters.

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

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

The description gives a specific verb and resource ('Get bounding box'), so an agent knows exactly what it retrieves. However, it never distinguishes this from the sibling get_assembly_bounding_box, leaving the part-vs-assembly scope ambiguous.

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

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

There is no when-to-use guidance at all: no statement of which document must be active, no conditions under which to prefer get_assembly_bounding_box or get_mass_properties, and no exclusions. The agent must infer applicability from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety and repeatability are covered. The description adds genuine context beyond that: the output unit convention (mm, degrees, kg) and the fact that results carry verification/error evidence. It still omits scope (whole document vs. individual body) and whether it requires a rebuilt model, so it remains a partial disclosure.

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

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

Three short, front-loaded sentences with the core action first, then units, then result characteristics. 'Through the independent native SOLIDWORKS engine' is partly promotional and 'Inspect verified measurements and error evidence' is vaguer than it needs to be, but nothing is bloated.

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, no-output-schema read tool, the description should say what quantities come back (mass, volume, centroid, moments of inertia) and what document state it operates on. Units and verification evidence are covered, but the returned fields and scope of measurement are left to 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?

There are zero parameters, so the baseline of 4 applies; the description's unit statement (mm, degrees, kg) usefully frames what the returned numbers mean, though it is output semantics rather than parameter semantics.

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

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

States a specific verb and resource ('Get mass properties') and names the underlying engine and unit system, so the agent knows it returns physical mass-property data. It does not distinguish itself from near-neighbours such as get_bounding_box, measure_distance or pro_verify_volume, and never says which document or body the properties apply to.

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: 'Inspect verified measurements and error evidence' suggests using it to confirm a model's physical characteristics, but there is no explicit when-to-use, no prerequisites (e.g. an active part document) and no guidance versus alternatives like pro_verify_volume or get_bounding_box.

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