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

No annotations are provided, so the description carries the full burden. It does disclose genuinely useful traits: it is a real geometry entity, it costs exactly 'one undo step', and all inputs are in metres. It omits permission/model-state requirements, what happens on invalid points, and what the call 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?

Two tight sentences: the entity type and its scope lead, followed by placement, undo cost, and units. Every clause carries information and nothing is repeated from the schema.

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

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

For a mutation tool with no annotations and no output schema, the definition covers the essentials (entity kind, undo cost, units, default tag) but leaves gaps around return value (e.g., the created entity handle) and failure/precondition behavior. Adequate, not complete.

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

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

Schema coverage is 50%: tag and offset are documented in-schema, while point_a/point_b have no descriptions. The description partially compensates by pinning the unit system ('all lengths and coordinates are in metres') and by echoing the default tag, but it adds nothing about the offset vector's direction/role or the point array format.

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

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

States a specific verb+resource ('Add a real linear dimension entity') and explicitly disambiguates from the nearest alternative ('not a text label'), so an agent knows this creates an actual measured dimension rather than an annotation string. It stops short of naming/contrasting with sibling tools like measure or create_edge.

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

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

Usage context is only implied: the parenthetical '(not a text label)' steers the agent away from one alternative, and the default tag hints at the typical drop layer. There is no explicit when-to-use vs. measure/create_edge guidance and no stated prerequisites (e.g., an open model or a sketch plane).

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

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

With no annotations, the description carries the full burden and does so well: it discloses the 50-item cap plus total counts, unconditional recursion into nested groups, the cross_group flag semantics, which faces are skipped (closed-solid end faces) and that they are still counted, and that all units are metres. It stops short of failure/permission behavior, but the operational disclosure is unusually rich.

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

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

Front-loads the purpose, and each clause is informative, but it is delivered as one long run-on paragraph dense with em-dash parentheticals that is hard to parse. A bulleted defect list would be more scannable for the same 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?

There is no output schema, so the description must describe returns, and it does: per-group counts, tiny_faces_by_group, the cross_group flag with separate counts, and the 50-item cap. An agent knows what to expect back and how to control verbosity; only the overall report framing is slightly underspecified.

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

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

Schema description coverage is 100% and already documents both parameters (group omission, ambiguous-name refusal, details being whole-model only). The description mostly restates this; its only real addition is the practical warning that details output 'can be very long'. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('check') and resource ('geometry problems' in groups), then enumerates the exact defect categories it detects (stray edges, open edges, non-manifold edges, duplicate edges, near-coincident vertices, tiny faces, non-planar faces, coplanar seams). This is instantly distinguishable from diagnostic siblings like measure or list_entities.

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

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

Gives clear operational routing: omit 'group' for a whole-model count-only pass, pass details:true for the (very long) example items, and 'audit one group to see where its issues are'. No explicit comparison to sibling tools, but the when-to-use guidance for its own two modes is concrete.

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

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

With no annotations, the description carries the full burden and does so well: read-only, does not itself count as a change, counter scoped per file path, bumped on commit/undo/redo, and tokens from a prior session are deliberately treated as changed to avoid false 'unchanged'. These are exactly the behavioral traits an agent needs to use the tool safely.

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

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

Purpose is front-loaded in the first sentence, then invocation, then return values, then the subtle session-id caveat. Information-dense and largely waste-free, though the final sentence is long and could be trimmed slightly.

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

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

No output schema exists, so the description correctly spells out the return values (current token, modified flag, and changed-since-token indicator). Combined with the session-id caveat, an agent has everything needed to call and interpret the tool.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining when to omit the token and what the token embeds (a per-plugin-load session id) with the resulting invalidation semantics. This meaningfully extends the schema's terse parameter description.

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

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

States a specific verb and resource: 'Check whether the model has changed since a previous look.' The polling/change-detection purpose is unambiguous and no sibling in the list competes with it.

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

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

Explicitly tells the agent to pass the token from the previous call and to omit it on the first call, which defines the correct invocation pattern. It doesn't frame alternatives, but there is no sibling overlapping this change-detection role, so the context is clear.

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

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

With no annotations, the description carries the full burden. It usefully declares global units (metres) and angle convention (degrees), which is real behavioral context beyond the sparse schema. However, it says nothing about reversibility, selection requirements, whether the arc is added to the active model, or what is returned — significant gaps for a creation tool.

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

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

Front-loaded with the action and kept to a few short sentences with no filler. Every sentence does work, though the units note partially overlaps the radius schema 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 a 9-parameter creation tool with no annotations and no output schema, the description is only partially complete: it covers the core geometry inputs and units but not the remaining optional parameters or the mutation behavior. Adequate but with clear gaps.

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

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

Schema coverage is 78%, just below the high-coverage baseline, and the schema documents most individual parameters. The description adds a global units/degrees clarification but mentions only center, radius, and angles, omitting layer, material, normal, xaxis, and segments.

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: 'Create an arc in SketchUp.' An agent can distinguish this from sibling create_circle/create_polygon/create_face without ambiguity. It stops short of naming those siblings explicitly, so it doesn't earn 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 when-to-use or when-not-to-use guidance and no alternatives named. The second sentence describes inputs rather than context, leaving the agent to infer that this is a drawing primitive versus a component or group operation.

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

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

With no annotations, the description carries the full behavioral burden. It states units (metres) and the default origin, but says nothing about permissions, whether the created entity is selectable/editable afterward, undo semantics, or failure modes for degenerate dimensions.

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

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

Three tight sentences that front-load the core action and then the optional origin, with no filler. The trailing unit statement is slightly redundant with the schema but reinforces the crucial metres convention.

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

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

For a 6-parameter geometry-creation tool with no annotations and no output schema, the description covers the geometric essentials but leaves layer/material unaddressed and the "named group" phrasing unexplained against the schema.

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

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

Schema coverage is 67%; the description usefully restates that width/depth/height and origin are in metres and defines origin as the base corner, but it omits the layer and material parameters entirely, leaving roughly a third of parameters 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?

The description gives a specific verb+resource ("Create a 3-D box (rectangular prism)") and clarifies it produces a named group, which distinguishes it from siblings like create_face, create_circle, or create_group. However, the "named group" claim is confusing because the schema exposes no name parameter, and no explicit sibling differentiation is offered.

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 alternatives such as create_face, push_pull, or create_component. The agent must infer usage purely from the name and geometry vocabulary.

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

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

With no annotations, the description carries the full behavioral burden, and it only partially does so. It discloses the return value ('returns edges forming the circle') and the unit convention (metres), but never says whether the geometry is actually committed to the model versus merely returned, whether it needs an active model or write permissions, or whether the operation is undoable. For an unannotated mutation tool this leaves significant ambiguity.

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

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

Two tight sentences with zero padding: the create action and its defining inputs come first, followed by the return value and the global unit convention. Every clause earns its place.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, the description covers the core geometry and the return shape but omits prerequisites, the fate of unspecified parameters, and any behavioral traits of the operation. It is adequate-but-gappy rather than complete.

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

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

Schema coverage is 67%, so the schema already documents center, normal, radius and segments. The description does add value by declaring that ALL lengths and coordinates are in metres, extending the unit contract the schema only states for radius, but it is silent on layer, material and segments, which have little or no schema description.

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

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

States a specific verb (Create) plus resource (a circle in SketchUp) and the geometric inputs that define it (center, normal, radius), which is enough to distinguish it from create_arc and create_polygon by implication. It stops short of explicitly contrasting itself with those siblings, so it lands just below the top band.

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

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

There is no when-to-use/when-not-to-use guidance and no named alternative: nothing tells the agent whether to reach for create_circle instead of create_polygon with many segments, or create_edge loops. No prerequisites (active model, edit context, units regime) are stated either.

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

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

With no annotations, the description carries the full behavioral burden. It usefully states that the definition is empty, that one instance is placed, and that all lengths/coordinates are in metres, which adds unit context. However, it omits permission requirements, side effects on model state, behavior on name collision, and whether the component definition is added to a library.

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: the core action, the return values, and the unit convention. Every sentence earns its place with no filler.

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

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

For a simple 3-parameter mutation tool with no annotations and no output schema, the description covers the action, return values, and units. However, it lacks explicit usage guidance against siblings and does not fully compensate for the undocumented 'description' parameter, leaving some gaps in behavioral expectations.

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 67%, with the 'description' parameter undocumented in both schema and description. The description adds important unit information ('metres') that applies to the origin coordinates, but it does not clarify the purpose or expected format of the optional 'description' parameter beyond what its name implies.

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 ('Create') and resource ('component definition'), plus the side effect of placing one instance. It implicitly distinguishes itself from 'place_component' by specifying a new empty definition, but it does not explicitly name the alternative or rule out related siblings like create_group or create_box.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention 'place_component' (for existing components), 'create_group' (for non-component groups), or any prerequisites. Usage is only inferable from the tool's name and purpose.

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

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

With no annotations, the description carries the full behavioral burden. It discloses units (metres), which is genuinely useful, but says nothing about side effects: whether the edge snaps/merges with existing geometry, what layer it lands on if 'layer' is omitted, what happens on duplicate edges, or what is returned. 'Create' implies mutation but the consequences are undisclosed.

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

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

Two tight sentences with the core action front-loaded and the unit convention following immediately. No filler, no redundancy with the schema.

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

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

For a simple three-parameter creation tool with no annotations and no output schema, the description covers the what and the units but omits layer defaulting behavior, success/return semantics, and any interaction with existing geometry. Adequate but thin given nothing else carries that 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?

Schema coverage is 67%: start and end are documented as '[x, y, z] point' while 'layer' is undocumented in both schema and description. The description adds real value with the metres unit statement, which the schema omits, but the unexplained layer parameter leaves a 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 (create) and resource (line segment/edge) with the spatial qualifier 'between two 3D points'. The parenthetical '(edge)' maps the plain-language term to the domain term, and the resource itself distinguishes it from create_face, create_box, create_circle, etc. It does not explicitly name siblings, but the resource specificity is strong.

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 alternatives (create_face, create_arc, create_polygon), and no prerequisites or preconditions. The agent must infer entirely from the name that this is the tool for drawing a single straight line.

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

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

With no annotations, the description carries the full burden. It usefully discloses the unit convention (metres converted internally to inches), which is real behavioral context, but says nothing about failure modes (e.g. non-coplanar or self-intersecting points), permissions, or whether an existing face is replaced.

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 unit statement is front-loaded and useful, but the description repeats 'metres' three times across two sentences, with the third clause being a redundant restatement of the first. It wastes space that could carry usage or failure-mode 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 mutation tool with no annotations and no output schema, the description covers the critical unit convention but omits failure behavior and return information an agent would need. Adequate but with clear gaps.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuinely non-schema information: the unit system (metres) for the points. This is essential to invoking the tool correctly and is not stated in the schema itself.

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 ('Create a flat face (polygon) in SketchUp') and the required input (ordered 3D points). It does not, however, differentiate itself from the sibling create_polygon or explain how a 'face' differs from a polygon/edge, leaving some ambiguity.

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

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

The description gives no guidance on when to use this tool versus siblings like create_polygon, create_edge, or merge_coplanar. It is purely a statement of what the tool does, with no context or exclusions.

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

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

No annotations are provided, so the description must fully disclose behavior. It mentions the group is empty and optional layer but lacks details on prerequisites, side effects, or what happens if no name is given.

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

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

The description is a single concise sentence that clearly communicates the tool's core function. It could be slightly more structured but is efficient.

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

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

Given the low complexity (2 parameters, no output schema), the description provides minimal viable information. It covers the basic operation but omits behavioral notes that would aid full understanding.

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

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

Schema coverage is 100% with descriptions for both parameters. The description adds minimal value ('empty named group', 'optionally on a layer') beyond the schema, so baseline score of 3 is appropriate.

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

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

The description clearly states the verb 'Create' and the resource 'empty named group', and specifies it's in SketchUp. It distinguishes from sibling tools like create_face and create_component.

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

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

The description implies basic usage (creating a group on a layer) but provides no guidance on when to use this tool versus alternatives such as create_component or when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It discloses only the unit system (metres) and that the polygon is regular; it says nothing about whether a face/group is created, how layer and material defaults behave, or whether the result is added to the model or an existing component.

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

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

Two short sentences with zero filler; the core purpose and the unit convention are front-loaded. Nothing could be trimmed without losing information.

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

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

For a 7-parameter geometry creation tool with no annotations and no output schema, the description is thin. It omits orientation behavior (normal), layer/material handling, inscribed vs circumscribed consequences, and what the tool returns, all of which an agent needs before invoking 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?

Schema coverage is 71%, with center, normal, radius, inscribed, and num_sides documented in the schema itself. The description adds a useful global note that all lengths and coordinates are in metres, which reinforces rather than extends the schema. It adds nothing about layer or material 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: 'Create a regular polygon ... with n sides', with examples (triangle, pentagon, hexagon) that pin down the geometry. It does not explicitly distinguish itself from close siblings like create_circle or create_box, but the resource 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 indication of when to use this versus create_circle, create_face, or create_box, and no prerequisites or context for when a polygon is the right primitive. 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?

With no annotations, the description carries the full burden and does meaningful work: it flags the unit convention ('unlike every other tool, this one uses US units') and describes the generated geometry ('proper web patterns, angled members, and realistic connections'). It still omits the side-effect shape (group/component creation, layer defaults) that a mutation tool benefits from disclosing.

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

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

Front-loaded with purpose, then constraints, then the critical unit caveat, then a resource pointer – a sensible information hierarchy. Slightly padded by the 'proper web patterns, angled members, and realistic connections' clause, which is more reassuring than 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 9-parameter mutation tool with no annotations and no output schema, the description covers units, variants, span bounds, and a guidance resource. It leaves the return/side-effect picture (what object is created, whether defaults apply) unstated, which is the main remaining gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by tying span ranges to each truss type and reinforcing the feet-vs-inches unit split across parameters. This is genuine added value rather than restatement.

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

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

States a specific verb and resource ('Create engineered roof trusses') and immediately differentiates scope by naming the two supported variants (king post, fink/W-truss) with span ranges. An agent can distinguish this specialized tool from the family of generic create_* siblings without opening any schema.

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

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

Gives clear selection context via the span ranges for each truss type (king up to 26', fink 20-60') and routes to the construction://roof-trusses resource for deeper guidance. It does not state explicit exclusions or contrast with an alternative truss tool, but none exists among siblings, so the omission is minor.

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

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

With no annotations, the description carries the full burden and does so richly: idempotency guard (refuses on existing opening), snapping tolerance (~3.5mm), a single undo step, an internal classify_point self-check with its result reported, and the composed world transform for nested walls. These are exactly the non-obvious traits an agent needs before invoking a destructive geometry 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?

Long but dense and front-loaded — the core action and its output geometry lead, followed by behavioral caveats. Every sentence conveys a distinct fact (nesting, from_floor, refusal, snapping, self-check, undo, frame, units), though the run-on density slightly hurts scanability.

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?

Despite no output schema, the description explains what is produced (face topology) and that the self-check result is reported. Combined with 89% schema coverage and 9 parameters, an agent has enough to call this complex tool correctly without further documentation.

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 89%, so the schema already documents most params, but the description adds real meaning: from_floor's face-splitting behavior, the optional U-shaped frame build, and the units convention ('all lengths and coordinates are in metres') which the schema omits. This goes beyond the baseline expected at high coverage.

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 with geometric detail: cut a rectangular opening (door/window) through a wall, producing holes in both faces plus reveal faces. This clearly distinguishes it from the inverse sibling fill_opening and from generic face tools like create_face.

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

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

Gives clear operating context: works on nested groups at any depth, refuses if an opening already exists (cannot double-cut), and from_floor:true selects the no-sill variant. It does not explicitly name alternatives such as fill_opening or push_pull, so it stops short of full when/when-not routing.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses execution scope, return behavior (last expression plus puts/print output), version-specific syntax limitations, Pro-only methods, undo requirements, and a clear warning that model data can be modified or deleted.

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

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

Front-loaded with the core purpose, then layered with operational details that each earn their place given the tool's power and danger. Despite its length, every sentence contributes actionable information without redundancy.

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

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

For a high-risk, annotation-free code execution tool with no output schema, the description covers execution context, return values, API access, version pitfalls, unit handling, Pro-only limitations, and undo discipline. It is complete enough for an agent to call it correctly and 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 100% for the single code parameter, so the schema already documents it. The description provides useful context about how that code runs but adds no syntax, format, or constraint details beyond what the schema states.

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

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

States the specific verb and resource: execute arbitrary Ruby code inside SketchUp. The description makes clear this is a generic scripting tool, distinct from all the specific modeling siblings like create_face or move_entity. An agent can immediately understand its unique role.

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

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

The description provides extensive operational context (top-level execution, API access, version constraints, undo wrapping) but never says when to choose this over a dedicated sibling tool or when to avoid it. Usage is implied for custom operations not covered elsewhere, but no explicit alternatives 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?

With no annotations, the description carries the full burden and does well: it enumerates the destructive steps (removes reveal faces, refills wall faces copying material/orientation, closes the bottom for a from_floor opening, erases seams), states the refusal condition, and discloses undo grouping ('One undo step'). It omits nothing major except any mention of what dry_run or group actually do.

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?

Single dense paragraph that front-loads the primary action before the mechanics, preconditions, and units. It is long but nearly every clause adds a distinct behavioral fact, with minimal filler.

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

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

For a mutation tool with no annotations and no output schema, the description supplies the safety-relevant behavior (destructive steps, refusal, single undo step) that an agent needs to call it safely. The remaining gap is that several input parameters, notably dry_run and group, are left entirely undefined.

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. It clarifies units ('metres') and defers the rectangle args to cut_opening, and from_floor/wall_faces are inferable from the prose, but dry_run, group, and axis are never explained 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?

States a specific verb+resource ('Fill a rectangular opening back in') and immediately lists the concrete effects, which cleanly distinguishes it as the inverse of the sibling cut_opening (explicitly named). An agent can identify it without opening the schema.

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

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

It anchors usage to the sibling ('Takes the same rectangle arguments as cut_opening') and gives an explicit refusal precondition ('Refuses if both wall faces are already solid there'). It does not spell out when-not to use it beyond that refusal, so it stops short of full alternative routing.

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

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

With no annotations provided, the description bears full burden for behavioral disclosure. It only states the action without mentioning whether the operation is destructive, modifies existing geometry, or requires any permissions. The description lacks important behavioral context.

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

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

Two concise sentences that immediately convey the tool's purpose and tie it to a familiar concept. No extraneous information; every sentence serves a 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 simple tool with only two parameters and no complex output, the description is fairly complete. However, it could mention whether the original face is preserved or if the operation is reversible, which would improve completeness slightly.

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

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

Schema description coverage is 100%, so baseline is 3. Description adds only minor clarification (path as array of edge IDs, reference to SketchUp tool) but essentially repeats what the schema already provides. No additional meaning is provided beyond the schema.

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

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

Description clearly states the tool extrudes a face along a path using edge IDs, and explicitly names it as SketchUp's Follow Me tool. This is a specific verb+resource combination that distinguishes it from siblings like create_face or move_entity.

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 tool versus alternatives. The description does not specify any prerequisites, context, or exclusions, leaving the agent to infer usage from the tool's function 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?

No annotations exist; description does not disclose any behavioral traits beyond the action. It does not mention that the tool is read-only, requires an open model, or any potential side effects or error conditions.

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

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

Single sentence that efficiently states the purpose and output details. No redundant or extra 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?

For a simple, parameter-less info tool, the description sufficiently explains what is returned. Minor gaps: no mention of prerequisites (e.g., model must be open) or error handling, but not critical for typical use.

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?

Tool has zero parameters; schema coverage is 100%. Description adds value by specifying the exact information returned, which is not inferable from the schema alone. Baseline of 4 is appropriate.

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

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

Description clearly states the tool retrieves general model information and explicitly lists the data fields (name, file path, unit system, entity/layer/material counts). This distinguishes it from sibling tools that focus on specific components (e.g., list_layers, list_entities).

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?

Description implies use for overall model stats but does not explicitly guide when to use this vs. sibling tools like list_layers or list_entities. No when-not-to-use or alternative recommendations are provided.

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

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

With no annotations, the description carries the behavioral burden and does well: it discloses returned fields, world-space coordinate behavior, applied active group/component transforms, and units. It does not state what happens when nothing is selected or how nested selections are handled, but the core read behavior is transparent.

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

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

The description is front-loaded and appropriately short for a simple getter. It repeats the metres convention twice, which is minor redundancy but not harmful.

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

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

Given no output schema and no annotations, the description does well by explaining the returned entity fields and coordinate system. It could be more complete by describing empty-selection behavior or the exact response envelope, but it is sufficient for correct invocation.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The baseline score of 4 is appropriate.

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

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

The description states a specific verb and resource: get the current SketchUp selection. It also enumerates the returned entity fields, making the tool's scope clear enough to distinguish it from siblings like list_entities or select.

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 'current selection' framing implies when the tool is useful, but there is no explicit guidance on when to use it versus list_entities, get_model_info, or select. Usage is inferable rather than stated.

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

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

No annotations are provided, so the description must disclose behavioral traits. It only states a read-only listing, but fails to mention potential performance impacts, whether it includes nested components, or any side effects. The brevity leaves significant behavioral ambiguity.

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

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

The description is a single, clear sentence with no wasted words. It is properly front-loaded and gets straight to the point.

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

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

For a simple list tool with no parameters and no output schema, the description fully captures the tool's behavior. It tells the agent exactly what the tool does without needing further elaboration.

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

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

The tool has zero parameters and schema coverage is 100%, so the schema provides complete information. The description adds no param details, but none are needed. With no params, a baseline score of 4 is appropriate.

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

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

The description explicitly states the tool's function: listing all component definitions. It is a specific verb+resource, and it distinguishes itself from sibling tools like create_component and place_component, which perform different actions.

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 alternatives like list_entities or get_model_info. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage without support.

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

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

No annotations are provided, so the description carries the full burden. The verb 'list' clearly implies a non-destructive read, and the statement that all lengths/coordinates are in metres is genuinely useful behavioral context. But it does not describe the return structure, ordering, or handling of empty/edge cases, which a no-annotation tool ideally would.

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

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

Two short sentences with zero filler; the core list scope is front-loaded and the unit convention follows as a compact clarifier. Every clause earns its place.

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

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

For a single-optional-parameter list tool with no output schema, the description covers what is listed, where, and the unit convention. It lacks return-shape and ordering details, but those are minor for a simple enumeration tool with no annotations to reconcile.

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

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

Schema coverage is 100% and there is only one optional parameter, so the schema already documents group_name fully. The description's phrasing 'inside a named group' is consistent but adds no semantics beyond the schema. Baseline 3 applies.

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

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

Specific verb+resource with an enumerated set of entity types (faces, edges, groups, component instances) and clear scope (model vs. named group). It distinguishes itself from list_materials/list_layers/list_components by the resource, though it doesn't explicitly name those siblings as alternatives.

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

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

Usage is implied through the optional group_name parameter ('if provided... otherwise top-level'), which tells the agent the two modes of operation. However, it never states when to prefer this over siblings like get_selection or list_components, nor any exclusions.

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

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

No annotations provided; description states basic read-only behavior but omits any side effects, permissions, or data volume considerations.

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

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

Single, informative sentence with no redundant words; front-loaded with key action and resource.

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 parameterless list tool, description covers what it does and what it returns (layers with visibility). Missing output format specification but acceptable given simplicity.

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?

No parameters exist, schema coverage is 100%, and description inherently covers all inputs. Baseline 4 is appropriate.

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

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

Description specifies verb 'List', resource 'layers (tags)', and additional detail 'with their visibility', clearly distinguishing from sibling tools like list_entities or list_materials.

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 tool versus alternatives; lacks any context about prerequisites or typical scenarios.

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

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

The description discloses the basic read behavior (listing materials) but does not detail side effects or permission requirements. Since no annotations exist, the description carries the full burden but is minimally adequate.

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

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

The description is a single, focused sentence that begins with the action verb 'List' and directly states what the tool does. No extraneous 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 parameterless list tool, the description adequately conveys purpose and output scope (materials with colors and textures). It could mention return format, but the simplicity makes this 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?

With 0 parameters and 100% schema coverage, baseline is 4 per guidelines. The description does not add parameter information because none are needed, making this appropriate.

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

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

The description clearly states the tool lists all materials, specifically mentioning colors and textures. This distinguishes it from sibling list tools like list_layers or list_entities.

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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions that might make this tool preferable.

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

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

With no annotations, the description carries the behavioral burden and does so well: it discloses the non-obvious 1.5mm clustering tolerance, the X/Y-only alignment constraint, and the unit convention (metres), while implying a read-only listing. It stops short of describing return shape details or any permissions/scale limits, so it isn't fully transparent.

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

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

Front-loaded with the core action and grouping rule, then parenthetical detail on tolerance, then scope limits. Every sentence contributes, though the density of parentheticals makes it slightly heavy for a listing tool.

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

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

For a 4-param read tool with no output schema and no annotations, the description explains the grouping algorithm, alignment filter, and units, and hints at the returned structure (grouped planes with each member's exact coordinate). It is nearly complete, missing only explicit return-shape detail and any mention of large-model performance.

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

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

Schema coverage is 100%, so the enum for axis, the group nesting/uniqueness rules, recursive, and min_height defaults are already documented. The description only adds the global unit convention ('all lengths and coordinates in metres'), which is useful but marginal beyond the schema, matching the baseline 3.

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

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

States a specific verb (List) and resource (vertical wall-like faces in a group) plus the grouping semantics, which clearly distinguishes it from siblings like list_entities or list_components. An agent can tell what this returns without opening the schema.

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

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

It clarifies the scope (vertical faces only, X/Y aligned, not diagonal) and notes it replaces manual scripting, which implies usage context. But it never states when to prefer this over list_entities or how it relates to move_plane/remap_planes siblings, leaving selection to inference.

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

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

With no annotations, the description carries the full burden and does so: it discloses return contents and ordering for probe mode, that gaps between crossings are directly room widths and wall thicknesses, recursive group scanning with innermost-group attribution, ambiguous-name refusal, and that all lengths are in metres.

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

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

Front-loaded with the one-line purpose, then enumerated modes, then return semantics. Dense but every sentence carries operative information; the mode descriptions are necessarily long because they encode mutually exclusive calling conventions.

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?

Despite seven parameters, zero required fields, nested objects and no output schema, the description supplies the mode-to-parameter mapping and the return shape, which are exactly the gaps the structured fields leave. An agent can call it correctly without further inference.

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

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

Schema coverage is 71%, and the description adds meaning the schema cannot: it binds the three modes to specific parameter pairs, clarifies face_id_* are persistent_id values, and explains group scoping semantics and the ambiguity-refusal rule. It stops short of documenting 'at' key requirements beyond what the schema already states via its example.

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

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

Opens with a specific verb and resource ('Measure distances') and immediately enumerates the three distinct modes with the exact parameter combination each requires. No sibling tool in the list performs measurement, so this is unambiguous against the surrounding CRUD/geometry verbs.

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 constraint 'provide exactly one' mode and the per-mode parameter recipes give clear selection guidance for an agent deciding how to call it. It stops short of stating exclusions or failure modes for a malformed call, so it is strong context rather than a complete when/when-not rubric.

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

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

With no annotations, the description carries the disclosure burden and does well: it declares the mutation is a single undo step, that it shares the post-check and change report of move_plane, that dry_run previews, and that ignore_back_material discards a material. It still omits any permission/context requirements or failure modes (e.g. what happens with locked groups).

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

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

Three sentences, front-loaded with the operation and its conditions, then behavioral facts, then the preview route. No filler and nothing buried.

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

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

For a mutation tool with no annotations and no output schema, the description covers the essentials: what changes, reversibility, preview mechanism, and material edge cases. The deferred 'same change report as move_plane' leaves the return shape implicit, which is a minor gap rather than a blocker.

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

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

Schema coverage is 67%: `group` and `ignore_back_material` are documented in the schema, while `dry_run` is not — but the description supplies that meaning explicitly ('or dry_run:true here'). The description therefore closes the one real gap rather than merely restating the schema.

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

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

States a specific verb and resource ('erase the seam edges between coplanar faces ... merging them back into single faces') with the precise preconditions (same orientation, same front/back materials, same group). This is enough to separate it from adjacent siblings like weld_vertices or audit_geometry without opening a schema.

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

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

Gives an explicit preview path: inspect audit_geometry's mergeable_coplanar_seams first, or run with dry_run:true here. That is clear routing guidance for a mutation tool, though it never states when the operation should be avoided (e.g. non-coplanar or intentionally seamed geometry).

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully states the translation-vector semantics and metre units, but for a mutation tool it omits whether the move is relative to current position, whether it is undoable, what permissions or selection state are required, and what happens to grouped or component entities.

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 no filler. The core operation is front-loaded, followed by the unit convention, so every sentence earns its place.

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

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

For a simple two-parameter mutation tool with a fully described schema and no output schema, the description covers the essential operation and units. However, with no annotations it should do more to describe mutation behavior, reversibility, and selection requirements before an agent can invoke it with full 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 100%, so both entity_id and vector are already documented in the input schema. The description reinforces the metre unit for the vector but adds no syntax or meaning beyond what the schema already provides, making the baseline 3 appropriate.

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

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

The description gives a specific verb and resource: 'Move (translate) an entity by a vector [x, y, z].' It is immediately clear what operation is performed. However, it does not differentiate from close siblings such as rotate_entity, scale_entity, or move_plane, leaving that distinction to the tool 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 explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative such as rotate_entity or scale_entity. Usage is only implied by the verb 'move'.

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

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

With no annotations, the description carries the full burden and delivers: single undo step, atomic abort on non-planar outcome, stranded-edge deletion, before/after count reporting, nested-group reach, refusal on partial-corner tilts or vertical/horizontal flips, and a multi-collection refusal with include/exclude as the override. This is unusually complete disclosure of mutation semantics.

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

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

Front-loaded with the core verb+resource+formula, then each following sentence conveys a distinct behavioral fact (undo, abort, edge cleanup, reporting, refusals, nesting, collections, dry_run, units). No filler or repetition of structured fields.

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

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

For a 13-parameter, annotation-free mutation tool with no output schema, the description covers the safety profile, refusal conditions, preview mode, units, and the return counts an agent needs to verify results. Nothing essential to calling it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains that include/exclude are how you acknowledge a deliberate multi-collection move, and that lengths are in metres. It ties the refusal behavior to specific parameters rather than merely restating them.

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

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

States a precise verb (move), the exact resource (every vertex on one axis-aligned plane of a group), the transform formula (by to - from), and even names the real-world operation it corresponds to (wall-move / room-resize). This lets an agent distinguish it from sibling move_entity without opening the schema.

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

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

Gives clear context (wall-move / room-resize), directs the agent to dry_run:true to preview, and routes verification to audit_geometry. It never explicitly names the alternative tool (move_entity) or states when-not to use this, so it falls short of a full 5.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it largely does not. It never says what happens when origin is omitted (origin is optional), whether the placement is undoable, or what the call returns. The units note is useful but is really parameter-level information rather than behavioral 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?

Two tight sentences, zero filler, with the core action front-loaded and the units constraint following. Nothing here is redundant with the schema.

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

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

For a mutation tool with no annotations, no output schema, and one undocumented parameter, the description covers purpose and units but stops short of the details an agent needs to call it confidently (origin default, coordinate order, return value). Adequate but visibly incomplete.

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

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

Schema coverage is 50%: name is documented in the schema, origin is not. The description partially compensates by declaring that all lengths and coordinates are in metres, which the schema omits, but it leaves the axis ordering of the 3-item origin array and the default when origin is absent unstated.

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

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

States a specific verb+resource ("place an instance of an existing component definition") and scopes it to a location in the model. The word "existing" implicitly separates it from create_component, but no sibling is named explicitly, so an agent must infer the distinction.

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

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

Usage is only implied: "an existing component definition" signals that the definition must already exist (via list_components/create_component) before this tool applies. There is no explicit when-to-use statement, no prerequisite ordering, and no named alternative.

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

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

With no annotations, the description carries the full burden. It usefully discloses the sign convention and that all units are metres, but for a mutation tool it says nothing about side effects on adjacent/connected geometry, whether new faces are created, or failure conditions.

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

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

Three short sentences, none wasted, with the core operation front-loaded ahead of the directional and unit conventions.

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

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

For a simple two-parameter modelling operation with no output schema, the description covers purpose, direction, and units, but omits side effects on neighbouring geometry and any indication of error or constraint behaviour that an agent would need before mutating a model.

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

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

Schema coverage is 100% and both parameter descriptions already state the units and the positive/negative meaning, so the description largely repeats what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

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 ('Push/pull a face') plus the effect's scope, which cleanly separates it from siblings like move_entity or scale_entity. The sign convention further pins down exactly what the operation does.

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

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

It explains how to use the distance value (positive extrudes, negative pulls) but never says when to choose this tool over alternatives such as move_entity or create_face. There are no exclusions or prerequisites, so an agent must infer the appropriate context.

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

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

With no annotations, the description carries the full burden and does well: it discloses the all-or-nothing abort, the silent-distortion failure mode it guards against, the nested-group reach, metre units, and that a change report is produced. The reference to guards 'the same as move_plane' assumes familiarity and leaves the guards themselves undefined, keeping it just short of 5.

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

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

Front-loaded with the core action, then the abort condition and failure rationale. Every sentence is informative, though the failure-mode explanation is slightly verbose for the space it occupies.

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

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

For a 10-parameter mutation tool with no annotations and no output schema, the description covers the important behavioral ground: undo semantics, abort behavior, guards, nested reach, units, and change report. Only the guard mechanics and full return shape remain underspecified, which is minor.

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 80%, so most parameters are already documented (map example, group resolution, include/exclude semantics, tolerance). The description adds the global metre-unit convention and reinforces shift_beyond, but does not expand on include/exclude or the guards' flags beyond what the schema states. Baseline 3 is appropriate.

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

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

States a specific verb (move), resource (parallel planes of a group), and scope (several at once, single undo step). This clearly distinguishes it from the sibling move_plane, which handles a single plane, and an agent can tell them apart without opening either schema.

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

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

The plural-planes/single-undo framing gives clear context for when to prefer this over move_plane, and it explains when to reach for the shift_beyond mode. It lacks an explicit 'use move_plane instead when...' exclusion, but the context is strong.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the unit system ('All lengths and coordinates are in metres'), which the schema does not state for the axis arrays, but it omits mutation semantics such as permission requirements, whether the rotation is relative to the entity origin, or how grouped/nested entities are 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?

Two tight sentences with the operation front-loaded and no filler. Minor redundancy in repeating the degree unit that the schema already specifies, but overall efficient.

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

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

For a 4-required-parameter mutation tool with no annotations and no output schema, the description covers what the tool does and its unit convention but leaves the geometry semantics (rotation reference point, effect on grouped entities, failure behavior) unspecified. Adequate but with clear gaps.

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

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

Schema coverage is 100%, so the schema already documents all four parameters including types and the [x, y, z] array shapes. The description adds the metre unit convention for the coordinate arrays, which is genuinely additive, but 'in degrees' merely restates the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Rotate an entity') plus the transformation model (around an axis, by an angle). It is clear on its own, but it does nothing to distinguish itself from the closely related siblings move_entity and scale_entity, which an agent must disambiguate 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, no prerequisites, and no mention of the alternative transform tools (move_entity, scale_entity). The agent is left to infer entirely from the name which transform tool 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?

With no annotations, the description carries the full burden. It usefully discloses one failure mode (model never saved), but says nothing about overwrite/disk-write behavior, permissions, or what success looks like – leaving significant behavioral gaps for a mutating 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?

Two short sentences, front-loaded with purpose and followed by the key precondition. Every clause earns its place with no filler.

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

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

For a zero-parameter, output-schema-less tool, the description covers purpose, scope, and a critical failure condition. It could mention that it writes to disk or any success return, but it is largely 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?

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics for the description to compensate for or clarify.

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

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

States a specific verb (Save) and resource (the current SketchUp model) with the scoping phrase 'in place,' which implicitly separates it from the sibling save_copy. An agent can tell what it does without opening a schema.

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

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

Provides a clear usage context ('in place') and a precondition for success ('fails if the model has never been saved'), but does not explicitly name save_copy or other alternatives. Clear context with no explicit exclusions.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the critical non-destructive property (open file untouched) plus the default timestamp suffix. It omits what happens if a file with that suffix already exists and gives no hint of any return value or path/permission constraints.

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

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

Three short sentences, zero filler, with the effect (copy beside the original) front-loaded ahead of the default and the usage cue. Every sentence earns its place.

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

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

For a one-optional-param, no-annotation, no-output-schema tool, the definition covers what it does, how it names output, its default, and when to use it. Only overwrite/collision behavior and return information are absent.

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

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

Schema coverage is 100% and the single optional 'suffix' parameter is already documented in the schema. The description adds the filename template that consumes the suffix, but no additional format or validation semantics. Baseline 3 applies when the schema does the heavy lifting.

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 ('Save a copy of the model') plus the exact resulting filename pattern '<name>_<suffix>.skp'. The clause 'leaving the open file untouched' distinguishes it from the sibling 'save' without needing either schema opened.

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

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

Gives a concrete scenario: 'Use this to take a backup before a risky batch of edits.' This tells the agent when to prefer it over 'save', though it never names 'save' as the alternative nor states when-not to use it.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the unit convention ('all lengths and coordinates are in metres'), which is real context, but says nothing about whether children/groups scale along with the entity, reversibility, or side effects on components.

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 verb and resource, then the two input formats, then the unit convention. Every sentence earns its place with no filler.

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

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

For a mutation tool with no annotations and no output schema, the description covers input format and units but leaves mutation semantics (children, reversibility, success/failure behavior) unstated. Adequate to invoke, incomplete for a 3-param write 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 100%, so the schema already documents all three parameters. The description restates the dual number/array semantics of 'scale' and adds the metres convention, but contributes little beyond what the schema provides.

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

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

States a specific verb and resource ('Scale an entity') that an agent can distinguish from siblings like move_entity and rotate_entity by the verb alone. It does not, however, explicitly name a sibling or scope boundary to sharpen the distinction.

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 move_entity, rotate_entity or push_pull, and no preconditions (e.g. whether the entity must be selected or ungrouped first). Usage must be inferred from the verb.

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

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

With no annotations, the description carries the full burden and does it well: it discloses that temporary state changes (camera, hidden tags/entities, section plane, guides) are rolled back, that the modified flag is preserved, and that no undo step is created. These are non-obvious side-effect guarantees an agent needs. It stops short of covering permissions, rate limits, or how the returned image is delivered.

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 dense, front-loaded sentences: the core action leads, followed by the behavioral caveats. No filler, and the important rollback/no-undo guarantee is prominent rather than buried.

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-param all-optional tool with full schema coverage and no output schema, the description supplies the purpose, the side-effect contract, and the output format (PNG). The only gap is the lack of detail on how the resulting image is returned or where it lands, which an agent might want.

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

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

Schema coverage is 100%, so the schema already documents all 8 parameters including the 'view' modes and defaults. The only description-level addition is the units note ('all lengths and coordinates are in metres'), which largely restates what the schema already says for view and section. Baseline 3 applies.

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

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

States a specific verb and resource ('Capture the SketchUp viewport as a PNG image') that no sibling tool duplicates, so the agent can identify it immediately. Distinct from zoom_to (which only frames) and save/save_copy (which persist the model).

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

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

The description implies the use case (rendering a view) but never states when to reach for this over alternatives or any conditions/exclusions. Some routing guidance leaks into the parameter text (e.g. section 'use with view:top'), but that is schema-level, not description-level.

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

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

With no annotations, the description carries the full burden and does so well: it discloses that selection is confined to the active editing context, that a nested target is silently substituted by its top-level container, and that the reply's 'notes' explain the substitution – non-obvious behavior an agent could not infer.

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

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

Front-loaded with the action and its purpose, then the identification rules, then the scoping caveat. The two sentences are dense but each clause adds decision-relevant information; minor tightening is possible but nothing is wasted.

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

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

For a 2-parameter, no-annotation, no-output-schema tool, the description covers the action, entity identification, scoping limits, substitution fallback, and the 'notes' feedback channel. Only group_names semantics and confirmation of non-destructive preview are left implicit.

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

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

Schema coverage is only 50%, so the description must compensate, and it does for 'ids' by warning against the volatile entityID/'id' field and pointing to persistent_id from get_selection/list_entities. 'group_names' is named but its semantics (matching rules, ambiguity) are not elaborated.

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 ('Replace the SketchUp selection') plus the motivating rationale ('so the user can see what the assistant means'). It is immediately distinguishable from the read-only sibling get_selection.

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

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

Explains the context in which it is used (previewing intent before a change) and offers two identification routes, ids or group_names. It does not state when not to use it or name alternatives explicitly, but the intended usage is clear.

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

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

With no annotations, the description carries the full burden and does well: it discloses that it is one undo step, that it aborts if a weld would split or fold a face, that cross_group leaves vertices as separate points, and that results surface in the near_coincident_vertices report delta. Auth/permission requirements are not covered, and dry_run/allow_splits effects are never described.

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

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

Front-loads the core purpose in the first clause, then layers scope distinctions. Dense but every sentence adds behavioral value; slightly run-on across the cross_group 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?

Given a 6-param mutation tool with no output schema, the description covers intent, scoping, abort behavior, undo semantics, and units well enough to call it correctly. The unmentioned dry_run and allow_splits flags are the main remaining gap.

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

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

Schema coverage is 67% (4 of 6 params documented), and the description meaningfully extends the keep parameter ('moves the nested one', default 'outer') and the cross_group behavior. However, dry_run and allow_splits are undocumented in both the schema and the description, leaving two mutation-affecting flags 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 ('Merge near-coincident vertex pairs in a group by moving one onto the other') and immediately qualifies the default scope (same entities collection) versus the cross_group variant. An agent can distinguish it from siblings like merge_coplanar or move_entity without opening the schema.

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

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

Gives clear context for use, including the practical symptom it fixes ('the deleting a line deletes the wall problem') and the exact condition that selects cross_group (vertices in different groups/components). It does not explicitly name or rule out sibling alternatives, but the when-to-use framing is strong.

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

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

With no annotations, the description carries the full burden, and it does disclose one key trait: "Does not modify the model," which tells the agent it is non-destructive to geometry. However, it omits what happens when both optional params are omitted (zoom to entire model?), whether both params can be combined, and what the call 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?

Two compact clauses, front-loaded with the action and scope, followed by the key non-mutation guarantee. No filler or redundancy.

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

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

For a simple two-optional-param camera tool with no output schema, the description covers purpose and the identifier semantics, but it is silent on the default behavior with no arguments and on the return value, leaving an agent to guess at edge cases.

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

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

Schema coverage is 0%, so the description must compensate, and it partially does by explaining that 'ids' are persistent_id values and 'group_names' are the alternative selector. It still leaves precedence/combination behavior and the default when neither is supplied 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?

The description names a specific verb ("Zoom/frame the SketchUp camera") and the resource it acts on (given entities), and clarifies the two identifier modes. No sibling tool in the list performs camera framing, so it is unambiguous against alternatives like screenshot or select.

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

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

Usage is only implied: an agent can infer this is for framing entities before a screenshot or inspection, but the description never states when to prefer this over select, get_selection, or screenshot. No exclusions or prerequisites are given.

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