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

With no annotations, the description fully discloses behavioral traits: the effect of operations on shared definitions, unreliability on non-manifold geometry, and the return format including how to interpret null bbox_mm for empty results. No contradictions.

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

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

The description is well-structured with the core purpose first, followed by clarifications and return details. Every sentence adds value, and there is no redundancy or wasted text.

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

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

Given the tool's complexity (4 parameters, one enum, no annotations), the description covers essential behavioral aspects and return format. It lacks detailed error conditions or prerequisites but is sufficient for most use 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?

All four parameters are fully described in the input schema (100% coverage). The description adds extra context beyond the schema, such as the special behavior on instances and the meaning of the difference operation, enhancing parameter understanding.

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 'Perform a boolean operation (union / difference / intersection) on two solids', specifying the verb, resource, and operation types. It uniquely identifies this tool among siblings as no other tool offers boolean operations.

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

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

The description provides clear context on when to use the tool, including the difference operation semantics and behavior on shared definitions. However, it does not explicitly state when not to use it or suggest alternatives, although no alternatives exist among siblings.

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

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

With no annotations, the description carries the full burden and does so richly: it discloses the geometric skip rules (seams <25°, concave edges, curved-surface segmentation), the -32602 failure for bodys with no feature edges and inside-out bodies, a 30 s timeout that rolls back with no changes, and unreliability on non-manifold geometry. It also tells the agent exactly which result stats to verify (subtract_failed, skipped_no_match).

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

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

The core operation is stated in the first clause, with skip rules, failure modes, timeout, and return shape following in logical order. It is dense but nearly every sentence carries behavioral information; the return-value recap is slightly redundant given the output schema.

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

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

For a mutation tool with no annotations, the description covers geometry preconditions, error codes, timeout behavior, reliability caveats, and post-call verification. Even though an output schema exists, the explanation of what stats mean and which to check adds real value.

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

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

Schema coverage is 100% and both parameters are documented there, so the baseline is 3. The description reinforces the mm unit and the all-edges scope of the operation but adds no syntax or format detail beyond the schema.

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

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

The description opens with a specific verb and resource: 'Chamfer (bevel) every feature edge of a group/component by distance mm.' That is unambiguous about what the tool does and its scope (all feature edges, not selected ones). It does not explicitly name a sibling like fillet_edge to contrast against, so it stops short of a 5.

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

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

Usage is heavily implied through edge-selection rules (seams under 25°, concave edges skipped) and failure conditions, which tells the agent when this tool will and won't work. However, nothing routes the agent between this and fillet_edge or boolean_operation, and there is no explicit 'use this when...' guidance.

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

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

No annotations provided, so the description fully covers behavioral traits: units (mm), minimum dimensions per type, position as MIN corner, per-type dimension conventions, return value details, and suggestion to verify with bbox_mm. Thorough 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?

Multiple sentences but each adds essential detail without redundancy. Well-structured: purpose, units, size constraints, anchor point, per-type dimension mapping, Group wrapping, return value and verification advice. Efficient and front-loaded.

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 100% schema coverage and presence of output schema, the description provides all necessary context: explains param nuances (ignored axis for cylinder/cone), behavioral constraints, and return format. No gaps for a primitive creation tool.

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

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

Schema description coverage is 100% (baseline 3), but description adds significant value: minimum sizes (0.1mm cube, 1.0mm sphere/cylinder/cone), clarifies that dimensions are interpreted differently per type (e.g., cylinder [0]=diameter, [2]=height), and reinforces that position is MIN corner.

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

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

Clearly states it creates a primitive (cube/cylinder/cone/sphere) in SketchUp and that geometry is wrapped in a Group. Distinguishes from transform_component by noting shared anchor convention, and from sibling creation tools by specifying primitive types.

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 clear instructions on when to use (to create primitives) but does not explicitly state when not to use or compare to alternative creation tools like create_dovetail or create_finger_joint. However, it references transform_component for positioning, offering some guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses partial-failure semantics (non-zero 'failed' means cuts did not apply, likely non-manifold geometry) and tells the agent to verify via bbox_mm. It omits mutation-side effects such as whether the joint is undoable or modifies the boards in place.

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

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

Front-loaded with the verb and resource, then constraints, then a compact return block. The restated angle range (0, 60] duplicates the schema constraint, a minor redundancy; otherwise every sentence earns its place.

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

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

For a 10-parameter geometry-creation tool with no annotations, the description covers the units convention, the positional precondition, default sizing assumptions, and failure interpretation of the return payload. An agent has everything needed to call it and to detect a bad result.

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

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

Schema coverage is 100%, so baseline is 3; the description still adds value by stating that offsets shift the joint from the board face's center and that defaults are sized for ~100 mm boards — context an agent needs to judge whether to override defaults.

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 dovetail joint between two boards' — which inherently separates it from the sibling joint builders create_finger_joint and create_mortise_tenon. It never explicitly contrasts the joint types, so the differentiation is left implicit.

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

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

Gives a concrete precondition — 'The two boards must already touch/overlap along the joint axis' — plus unit and angle-range constraints. It offers no explicit when-not-to-use guidance or routing to the alternative joint tools.

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

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

No annotations are provided, so the description carries the full burden and does it well: it declares units, warns that defaults assume ~100 mm boards, states the geometric precondition, and explains the failure mode ('non-zero failed means some cuts did not apply (likely non-manifold geometry)') with a verification path via bbox_mm. It stops short of saying the operation mutates both boards irreversibly or how to recover.

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 blocks, front-loaded with the action, then units/defaults, then the return contract. Every sentence carries information; only the listed return fields overlap with the output schema.

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

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

For a nine-parameter mutation tool with no annotations, the description covers units, default sizing, geometry prerequisites, and the failure/verification story — enough to call it correctly. It omits whether the operation is reversible and what happens to board identity on partial failure.

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 real meaning: it restates the unit convention at the tool level and notes that defaults are sized for ~100 mm boards, which the schema does not convey. The offset-centering semantics are already in the schema, so this is a modest lift over baseline rather than a large one.

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 finger joint (box joint) between two boards' — and names the synonym so an agent won't confuse it with the dovetail or mortise-tenon siblings. The two named boards make the operation's scope unambiguous.

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

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

Gives a concrete precondition: 'The two boards must already touch/overlap along the joint axis', which tells the agent when the call is valid. It doesn't explicitly route to create_dovetail or create_mortise_tenon as alternatives, so selection between joint types is left to inference.

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

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

No annotations are provided, so the description must disclose behavioral traits. It states the tool creates a layer and returns {id, name, visible}, which covers mutability and output. However, it does not disclose any side effects, permissions, rate limits, or constraints beyond the schema (minLength). For a simple creation tool, this is adequate but minimal.

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 extremely concise—two sentences: one for purpose and one for return value. No unnecessary words, front-loaded with the action. Every sentence adds value.

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 tool's single parameter and the presence of an output schema (which the description explicitly echoes), the description is complete. It covers purpose, input, and output. No critical information is missing for an agent to use this tool correctly.

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

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

Schema coverage is 100% for the single parameter 'name', which already has a description. The tool description adds no additional meaning beyond the schema for this parameter (just 'with the given name'). Baseline 3 is appropriate.

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

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

The description clearly states the verb 'Create' and the resource 'new layer (tag)' with a required name parameter. It distinguishes from sibling list_layers which reads layers, and other tools that modify components. The return format is also specified.

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

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

The description implies usage for creating a layer, but does not explicitly state when to use this tool versus alternatives like list_layers or other creation tools. No when-not or exclusion criteria are provided, but the simplicity of the operation mitigates the need for extensive guidance.

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

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

With no annotations provided, the description carries full burden. It explains dimensions are in millimeters, offsets from board face center, and details the return format including how to interpret failed cuts: 'non-zero failed means some cuts did not apply (likely non-manifold geometry); verify via bbox_mm.' This is a good disclosure of behavior and failure mode.

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

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

The description is concise: two paragraphs with no filler. The first sentence states purpose, followed by critical details. Every sentence adds value, and the structure is front-loaded.

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 tool has 8 parameters, an output schema, and no annotations, the description covers prerequisites, unit system, default sizing, return format, and error handling. It is complete enough for an AI agent to understand what the tool does, when to use it, and how to interpret results.

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. The description adds some context (units, default sizing) but does not significantly enhance understanding of individual parameters beyond the schema. The explanation of mortise_id and tenon_id is already present in the schema's description field.

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

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

The description clearly states the tool's purpose: 'Create a mortise-and-tenon joint between two boards.' It uses a specific verb (create) and resource (mortise-and-tenon joint), which distinguishes it from sibling tools like create_dovetail or create_finger_joint.

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 explicit prerequisites: 'The two boards must already touch/overlap along the joint axis.' Also notes that defaults are sized for ~100 mm boards, giving a usage hint. Does not explicitly state when not to use or list alternatives, but sibling tools provide that context implicitly.

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

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

With no annotations, the description must carry the full behavioral burden. It does disclose the failure mode (error code -32602 for unsupported entity types) and the return shape, which is useful. But it omits key delete semantics: whether child entities are deleted with the parent, whether the operation is undoable, and whether it requires the instance to be unique versus a definition shared elsewhere.

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 plus a return note, with the core operation and its validity constraint front-loaded. Nothing redundant; the error code carries real information.

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

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

An output schema exists, so explaining the return value is optional (the description does so anyway). For a destructive, no-annotation tool, the missing pieces are cascade behavior and undo availability, which an agent arguably needs before deleting a component instance.

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

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

Schema coverage is 100% and the schema already explains the id parameter as 'Entity ID from a previous response'. The description adds constraint meaning beyond that by limiting the valid ID to groups/component instances, which is the crucial semantic the schema lacks.

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 ('Delete a group or component instance by entity ID') and explicitly bounds the accepted entity types, distinguishing it from sibling mutation tools like transform_component or create_component. An agent can identify the operation and target object type 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 states the negative case clearly ('Raw faces, edges and other entities fail with -32602'), which implies this tool is only for group/component instances. However, it never names an alternative for deleting raw geometry, so the agent is told what not to pass but not what to use instead.

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

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

With no annotations provided, the description carries the full burden and excels. It discloses that only the last expression's .to_s is returned, stdout is not captured, errors are returned as '[code] message' with the Ruby exception class, and describes the gate-closed scenario including the JSON-RPC code and how the message is surfaced. This gives an agent a clear picture of what to expect before calling.

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 moderately long but every sentence adds essential detail: purpose, gating behavior, return value nuances, and error format. It is front-loaded with the core purpose in the first sentence and then expands on critical behavioral details. No fluff is present, but it could be tightened by reducing the explanation of the gate message wrapper, which is somewhat tangential to the core call.

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

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

The description covers all critical aspects an agent needs to call it correctly: return format, stdout limitation, error handling, and the special gate-closed case. It also alerts the agent to the verbatim-message mechanism. For a single-parameter tool with an output schema (though not shown), this is complete enough for accurate 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 schema already describes the parameter with 100% coverage, so the baseline is 3. The description adds valuable usage guidance by advising to end scripts with an explicit expression like 'result.to_json' to obtain structured data, which directly affects how the parameter should be used. This elevates it above baseline.

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

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

The description opens with 'Evaluate arbitrary Ruby code in SketchUp,' a specific verb and resource that unambiguously distinguishes it from all sibling tools which perform specific operations (create_layer, undo, get_version, etc.). There is no ambiguity about what the tool 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?

The description does not explicitly contrast this tool with its siblings or state when to prefer it over other tools. It explains the gating behavior and error handling, but this is about behavioral context, not usage routing. The implied usage is as a general-purpose escape hatch for operations not covered by the specialized tools, but that is left to inference.

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

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

With no annotations, the description carries the full burden and does so: it discloses the file lands on the SketchUp host (not locally), the error code -32602 and its cause for skp on untitled models, that other formats still work in that state, and the default 1920×1080 render size. These are non-obvious failure modes an agent could not get from structured fields.

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

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

The purpose leads, followed by a grouped format list, host caveat, error condition, and return shape. Every line adds information; nothing is padded.

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

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

An output schema exists, yet the description still names the return shape ({path, format}) briefly without over-explaining. For a single-parameter tool with meaningful host/config caveats, all decision-relevant context is present.

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

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

Schema coverage is 100% and the enum is already documented, so the baseline is 3. The description adds value beyond the schema by explaining the png/jpg default resolution and by tying the skp format to the untitled-model error, which the schema alone does not convey.

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

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

"Export the current scene to a temp file on the SketchUp host" gives a specific verb, resource and destination. It doesn't explicitly differentiate from the closest sibling, get_viewport_screenshot, so an agent must infer the difference (file on disk vs. inline image) from the format list.

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 split-host caveat ("the path is not directly readable here") effectively tells the agent when this tool's output is unusable in the current context, and the untitled-model note states a precondition. It stops short of naming an alternative tool for the viewport-render case.

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: a 30 s in-SketchUp cut budget with full rollback, a -32602 failure mode for bodies with no straight feature edges and for inside-out bodies, a remediation hint (reverse faces first), and an unreliability warning on non-manifold geometry. It even tells the agent which stats counters to validate after the call.

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 failure and return-value details in descending priority — good structure. Minor waste in the self-restating parenthetical 'edges where the surface bends by less than 25°: the two face normals differ by under 25°'.

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 an output schema existing, the description adds the interpretive layer the schema cannot: what each skip counter means and the invariant that subtract_failed and skipped_no_match must both be zero. Combined with the timeout and geometry-precondition notes, an agent has everything needed to call this correctly and to interpret a suspicious result.

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

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

Schema description coverage is 100%, so id, radius, and segments are already documented including units and the 1–32 range. The description restates 'radius mm' and 'segments arc segments' without adding meaning such as how segment count trades off against file size or cut time. 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+resource+scope: round (fillet) straight feature edges of a group/component by a given radius and segment count. That is concrete enough to act on. It never names the obvious sibling chamfer_edge, so nothing in the text routes the agent between the two bevel-like operations.

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

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

Gives strong implied usage boundaries by enumerating what is skipped (seams under 25°, curved rims, concave edges) and which bodies fail outright (cylinder, cone, sphere, inside-out). What's missing is explicit routing to alternatives — e.g. 'use chamfer_edge when you want a flat bevel' — so the agent must infer the choice.

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

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

With no annotations, the description fully explains behavior: case-insensitive substring matching, exact layer matching, recursive search bounded by max_depth, pagination with truncation, and return format. No contradictions.

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?

6 sentences front-loading purpose, then detailing matching, filter-less behavior, and return format. No extraneous text.

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

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

Covers all key aspects: filtering criteria, recursion, pagination, return structure. Output schema exists but description still gives helpful summary.

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 has 100% coverage with good descriptions. The tool description adds behavioral context (case-insensitive, exact, recursive) not in schema, enhancing understanding.

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 finds components by name substring, layer, and type. It explains matching rules (case-insensitive, exact layer) and distinguishes from sibling list_components by noting the same traversal when no filters are applied.

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

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

The description mentions that without filters it behaves like list_components, implying an alternative for unfiltered listing. However, it could explicitly state when to use find_components vs list_components.

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 full burden. It states the return format but does not disclose error behavior, permissions, or that it is read-only. For a simple getter, this is minimally acceptable.

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

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

Two sentences fix, no unnecessary information. Concisely states purpose and return format.

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

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

Given the simple input and presence of output schema, the description is largely complete. It could mention error handling or that the ID must come from previous responses, but overall is sufficient.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add new meaning beyond the schema's 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?

The description clearly states the tool retrieves detailed info for a single group or component by entity ID, distinguishing it from sibling tools like find_components, list_components, and 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?

The description implies usage when the user has an entity ID, but lacks explicit guidance on when to use versus alternatives, or when not to use this tool.

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

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

No annotations are provided, so the description carries the burden. It implies a read-only operation but does not explicitly state that it does not modify the model or any side-effect guarantees.

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

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

Two sentences, no waste. The first sentence states purpose, the second lists return format concisely.

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 info retrieval tool with no parameters and an output schema, the description is largely sufficient. However, it misses potential preconditions (e.g., model must be open) and failure modes.

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 (0 params), baseline is 4. The description adds value by detailing the return structure beyond the empty schema.

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

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

The description clearly states 'Get current SketchUp model info' and lists all returned fields (path, title, units, etc.). It is specific and distinct from sibling tools like get_component_info which focus on individual components.

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 explicit guidance on when to use this tool vs alternatives. The context is implied as a general model information retrieval, but there is no mention of when not to use it or prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It details the output format and differentiates entity types, but does not mention side effects, permissions, or behavior in empty selection.

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 plus an example schema structure. No wasted words, highly 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 tool's simplicity (no parameters, straightforward purpose), the description fully explains what it returns and the format. Output schema exists, so no need for further return value explanation.

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, and the description provides no parameter information, which is appropriate since there are none. Schema coverage is 100%, so baseline score of 4 is suitable.

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 ('Get') and the resource ('entities currently selected in the SketchUp UI'). It differentiates itself from sibling tools like boolean_operation or create_component by being a read-only getter.

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 or when not to use it. For a simple getter, the necessity may be obvious, but explicit context would improve clarity.

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 it well: it discloses the always-returns-a-payload guarantee, including under connection failure, which is the key non-obvious trait of a diagnostic probe. It does not mention latency, authentication needs, or side effects, but the tool is plainly read-only.

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

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

Front-loaded with the purpose, then the usage hint, then the payload fields. The field enumeration partially duplicates the output schema, which is mild waste, but it is short enough to read in one pass and nothing is filler.

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

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

An output schema exists, so the description needn't restate return fields, yet it does describe error handling ('error (string | null)') and payload guarantees that the schema alone would not convey. Within that richness, the only missing piece is any note on cost/latency or failure modes of the probe itself.

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?

Zero parameters, so the baseline is 4. The description additionally explains the shape of the returned payload, which is the only semantic content this tool has.

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 ('Return the server version and Python↔Ruby compatibility verdict'), which is clearly distinguishable from every sibling tool (component operations, eval_ruby, viewport screenshots). An agent knows immediately 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?

Explicitly frames the tool as a 'runtime sanity probe' usable even when the connection or other tools error, which gives a clear use condition. It stops short of naming when NOT to use it or pointing at alternatives, but for a diagnostic no-arg tool the guidance is sufficient.

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 describes the snapshot process, parameter effects, and retry/flicker behavior. It does not explicitly state non-destructiveness but implies it via the restore_view parameter and its description.

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

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

The description is well-structured with clear paragraphs and a parameter list. It is concise enough but could be slightly tighter by removing some redundancy.

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

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

Given no output schema, the description includes the return format (PNG + JSON). It covers all parameters, retry behavior, and the purpose, making it fully informative for an agent.

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%, but the description adds significant context beyond the schema for each parameter, such as aspect ratio scaling for max_size and the specific rendering options toggled by style.

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 captures a screenshot of the SketchUp viewport and returns a PNG image along with a JSON block containing dimensions and style info. It is distinct from sibling tools like export_scene or 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?

Explicitly states it is 'useful for letting Claude visually verify the scene between steps', providing clear context for when to use it. However, it does not explicitly mention when not to use it or compare with alternatives.

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

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

With no annotations provided, the description fully bears the burden of behavioral disclosure. It explains the return format (detailed vs. concise), pagination behavior (truncated flag, offset increment), and recursion depth limits. This is comprehensive for a read-only list operation.

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

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

The description is concise (three short paragraphs) and well-structured: purpose, object format, parameters, return value with pagination instructions. Every sentence adds value 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?

Given the tool's complexity (5 parameters, pagination, two response formats), the description covers all necessary aspects: what is returned, how recursion works, and how to paginate. The presence of an output schema is acknowledged but the description still fully explains the return structure.

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 each parameter is already described. The description adds significant value by explaining the meaning of response_format (detailed includes bbox_mm, concise omits it) and the interaction between recursive and max_depth. This goes beyond the schema.

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

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

The description begins with a clear verb+resource: 'List groups and component instances in the model (paginated)'. It immediately distinguishes itself from siblings like find_components (search) and get_component_info (single component), as it is a paginated listing tool.

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

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

The description provides clear guidance on using pagination and recursion (e.g., 'Set recursive=true to descend into nested components... bounded by max_depth, default 3' and instructions for pagination via offset increment). However, it does not explicitly state when to use this tool over siblings like find_components, which would improve the score.

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, so description carries full burden. It mentions return format and that it lists all layers, implying a read-only operation but does not explicitly state no side effects. Adequate for a simple 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?

Very concise, single sentence plus return format example. Structurally clear and front-loaded.

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

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

Given zero parameters and presence of output schema in description, it is fairly complete. Lacks details on layer definitions or edge cases, but sufficient for a simple list 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?

No parameters exist, so schema coverage is 100%. Baseline of 3 applies; description adds no parameter information, which is acceptable given no params.

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 model layers (tags). The verb 'list' and resource 'layers' are specific. The parenthetical 'tags' might cause minor ambiguity but overall the purpose is clear.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., create_layer). However, as a simple read operation with no parameters, usage context is implicitly understood.

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 case-insensitive matching, accepted color names and hex syntax, the -32602 failure mode, instance-unique side effects for groups/components, shared-definition coloring for raw face/edge IDs, and the return shape.

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

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

The first sentence is front-loaded and establishes purpose immediately. The remaining details are dense but mostly necessary for correct invocation, though the description runs several paragraphs and the color enumeration is lengthy.

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, the description covers validation rules, side effects, uniqueness behavior, and return values. An output schema exists, but the description still supplies essential operational context an agent needs before calling 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 100%, so baseline 3 applies, but the description adds meaningful semantics beyond the schema: material matching rules, an exhaustive named-color list, hex format, failure behavior, and id provenance via get_selection.

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: assigning a material/color to a group, component instance, face, or edge. The target taxonomy is explicit enough that an agent can distinguish this from siblings such as transform_component or 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?

Makes clear this is the tool for painting entities with a material and points to get_selection as the source for raw face/edge IDs. It lacks explicit when-not guidance, but no other sibling appears to perform material assignment, so the context is clear without 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 exist, so the description carries the full burden and does so: it discloses application order (position applied LAST, after rotation/scale), rotation axis order, relative-vs-absolute distinction, idempotency of repeated position, the -32602 failure mode, validation scope versus eval_ruby, and the return payload including bbox_mm being null for empty geometry.

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

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

Front-loaded one-line summary, then per-parameter bullets, then return contract — no wasted sentences despite the length. The repetition about position not being a relative offset earns its place because it prevents the most likely misuse.

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?

Complete for a 4-parameter mutation tool with no annotations: semantics, ordering, failure mode, validation scope, and the verification signal (read bbox_mm) are all present. The output schema exists, and the description's brief return note is appropriately light.

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%, but the description goes well beyond it: it explains that position is an absolute bbox-min target rather than a relative offset, that it is applied after rotation/scale so bbox-min lands exactly at [x,y,z] in combined calls, and that rotation/scale are relative about the bbox center. Those composition semantics are not derivable from the schema alone.

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 set and resource (move/rotate/scale a group or component) with units (mm / degrees), and explicitly scopes the entity types it accepts versus the -32602 failure case. An agent can distinguish it from create_component, delete_component, and eval_ruby without opening the schema.

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

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

Explicitly names the entity restriction ('Groups and component instances only; other entities fail with -32602') and clarifies the relationship to create_component's anchor and to raw eval_ruby, which bypasses these validations. It does not explicitly state when to prefer eval_ruby or a different transform route, 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, the description carries the full burden. It discloses that it undoes the last atomic operation and returns {ok: true}. This sufficiently describes behavior for a straightforward undo tool.

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

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

The description consists of two short sentences: one explaining the action and one specifying the return value. Every word adds value with no redundancy.

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

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

Given no parameters and a simple return, the description is complete. It omits potential edge cases (e.g., multiple undos), but overall it provides sufficient context for a basic undo 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?

There are no parameters (0 parameters, 100% schema coverage). The description adds no extra parameter info, which is fine as the schema already covers everything.

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 'Undo the last atomic operation in SketchUp', using a specific verb and resource. It is distinct from sibling tools which create, modify, or query; no other tool performs undo.

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

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

The description explains that one MCP tool-call equals one undo step, clarifying usage. No explicit when-not-to-use or alternatives are given, but the simple 0-parameter interface and unique function make guidance adequate.

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