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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the mutation/safety profile is covered. The description adds real value beyond that: it discloses that missing tags/materials are auto-created (a side effect), and the subtle rule that color only applies when the material is newly created while an existing material keeps its color.

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, then dimensions, origin, material/tag behavior, and return shape. Dense but every clause carries information; only the parenthetical color caveat is slightly heavy, and the whole thing stays readable.

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 output schema, the description covers the essentials: units, axis semantics, origin convention, side effects, color semantics, and even the return object shape. Combined with annotations that carry the safety profile, nothing critical to correct invocation 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 only 50%, so the description must compensate, and it does: it defines the axis mapping (width=X, depth=Y, height=Z, mm), clarifies origin is the lower-left corner, and supplies the color format ('#RRGGBB' or color name) plus its conditional application. The undocumented tag/material parameters are partly addressed by the auto-creation note, though their exact expected values remain implicit.

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

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

States a specific verb (Create) and resource (rectangular box/group) with axis orientation for each dimension, which cleanly separates it from siblings like create_shape, create_lines, and insert_component. An agent can identify exactly what this tool produces 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?

Usage is implied (creating a box primitive) but there is no explicit when-to-use or when-not-to-use guidance, and no routing against create_shape or insert_component. The agent must infer the choice from the resource name alone.

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

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

Annotations already establish a non-read-only, non-destructive write. The description adds real context beyond that: geometry is placed in a new group, close_face changes topology by creating a face, and the result is signaled via a face_created field. It omits failure modes and return structure detail, keeping it from a 5.

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

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

Two tight sentences, front-loaded with the core action, and no wasted words. The conditional behavior is packed efficiently into a single clause.

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

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

For a 4-parameter creation tool with 0% schema coverage and no output schema, the description is only partially complete. The points and close_face behavior are covered, but tag/name meaning and the overall return shape remain unaddressed.

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

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

Schema coverage is 0%, so the description must carry the load. It clarifies the points format ([x,y,z] mm) and the close_face semantics, covering half the parameters well, but tag and name are left completely undocumented in both schema and description.

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

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

States a specific verb (Draw) and resource (polyline) through [x,y,z] mm points in a new group, which is clearly distinguishable from creation siblings like create_box and create_shape. It does not explicitly name those siblings, 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?

There is no explicit when-to-use or when-not-to-use guidance, nor routing to an alternative tool. The conditional 'close_face=true' explanation implies usage but does not tell an agent when this tool is the right choice versus create_shape or create_box.

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

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

Annotations declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description's added context is the real value here: it discloses that geometry is created inside a new group and that pushpull turns the face into a solid. It does not describe failure behavior for non-coplanar or self-intersecting points, which is the main remaining behavioural gap for a mutating geometry tool.

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

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

Two front-loaded sentences plus a compact return-field list; the polygon constraint and the extrusion behaviour appear before the return signature. Minor redundancy with the schema's own points description ('coplanar points') is the only waste.

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 correctly enumerates the returned fields (id, persistent_id, type, name, tag, material, bounds_mm). Units are stated for both geometric inputs and the group-creation side effect is disclosed, which is enough for an agent to invoke this confidently in a local SketchUp context.

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

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

With schema description coverage at only 33%, the description carries most of the load and does so for the two parameters that matter: points (mm, >= 3 coplanar, ordered around the perimeter) and pushpull (mm, extrudes into a solid). It leaves tag, material, color and name undefined, so an agent receives no hint about whether tag/material must reference existing list_tags/list_materials entries or what color format is accepted.

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 ('Draw a flat face from a polygon') plus the optional extrusion outcome, which is far more informative than the bare name create_shape. It does not explicitly name or contrast with the sibling tools create_box or create_lines, so an agent must infer the distinction from the polygon-input requirement rather than being told 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?

The parenthetical '(e.g. draw a floor outline, then pull it up to the slab thickness)' gives a concrete usage scenario, which implies when the tool is appropriate. However, there is no explicit when-not guidance and no routing to alternatives such as create_box for box geometry or insert_component for pre-built objects.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the danger is known. The description adds genuinely new behavioral context by stating the operation 'can be undone', which materially changes how an agent should weigh the risk, plus the guarantee that a selection alone will never trigger a delete. It stops short of describing child/component propagation.

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 filler; the destructive scope constraint and the reversibility note are both front-loaded. Every clause carries information.

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

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

For a one-parameter destructive tool with full schema coverage and no output schema, the description covers the key questions: what it acts on, what it will not act on, and that the effect is reversible. It could say more about cascading effects on nested entities, but nothing essential is missing.

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

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

Schema description coverage is 100% and the single parameter is fully documented, including where valid ids come from and their session-scoped validity. The description restates 'ids are required' (already in the schema's required list) and adds only the negative constraint about selection, so baseline 3 is correct.

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

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

States a specific verb and resource ('Delete entities by id') and immediately bounds the operation ('never deletes by selection'), which cleanly separates it from select_entities, transform_entities, and the create_* siblings. An agent can pick this tool without opening any schema.

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

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

It makes the input requirement explicit ('ids are required; never deletes by selection'), implying the agent must first obtain ids rather than acting on a live selection. It does not name the sibling to use for that step (e.g. selection_info), so the alternative-routing is implied rather than spelled out.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the agent knows this writes rather than reads. The description adds useful context (extension-driven format selection, Pro licensing requirement) but never explains what is actually destructive — e.g. whether an existing file at path is overwritten, or what happens on an unsupported extension.

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 mechanism (extension chooses format) is front-loaded and the licensing caveat follows immediately after.

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, one required parameter, and mutation-style annotations. The description covers format selection and licensing, but for a file-writing tool it leaves the agent guessing about overwrite semantics, path resolution, and what the call returns on success or 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 0% for the single 'path' parameter, so the description carries the burden. It does add real meaning by explaining that the path's extension selects the output format, but it omits whether the path is absolute or relative, whether the target directory must exist, and overwrite behavior.

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 (export), resource (the model), and the selection mechanism (file format driven by extension), with a concrete format list. It implicitly separates itself from the export_png sibling by listing only geometry/CAD formats, but it never names or contrasts that sibling explicitly.

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

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

The format list implies the situations this tool covers, and the note that some formats need SketchUp Pro is a real prerequisite. However, there is no explicit guidance on when to choose this over export_png, save_model, or screenshot, and no stated conditions under which the call will fail.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the write profile is covered. The description usefully adds that 'view changes the camera first' (a state side effect) and that dimensions are in pixels, but it never explains the destructive hint — file overwrite behavior, failure modes, or permissions are unstated.

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

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

Two short, dense sentences, front-loaded with the core action and example, then the two most easily misused parameters. 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?

Wait—reconsidering: for a 5-parameter destructive write tool with no output schema and 0% schema coverage, the description omits the overwrite semantics implied by destructiveHint=true and the 'transparent' parameter entirely.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate. It clarifies 'path' via example and gives units for width/height plus the camera side effect of 'view', but says nothing about 'transparent' or how PNG vs JPG is selected (presumably the extension).

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: 'Export the viewport as a PNG/JPG file', with a concrete path example. It does not, however, distinguish itself from close siblings such as 'screenshot' or 'export_file', so an agent cannot tell them apart from this text 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 when-to-use guidance and no mention of the obvious alternatives ('screenshot', 'export_file') that appear in the sibling list. The reader must guess which export tool to pick.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds behavioral context by disclosing the position unit (mm) and that rotation is about the Z axis, but says nothing about mutual exclusivity of path/definition, error behavior, or reversibility.

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

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

Two tight sentences, front-loaded with the verb and resource, then the sourcing options, then positional details. There is little waste, though the parameter-level facts could be organized more scannably.

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, zero-required mutation tool with no output schema and no annotations beyond safety, the description covers the core insert workflow but omits the meaning of tag/name/material, whether path and definition are mutually exclusive, and what happens on failure. 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 only 14% (just 'position'), so the description must compensate, and it does explain path (with a concrete example), definition (definition = name), position units, and rotation_deg semantics. It leaves tag, name, and material completely undocumented, so roughly half the parameters still lack meaning.

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 ('Insert') and resource ('a component') and disambiguates the two insertion sources (a .skp file via path, or an in-model definition via name). It implicitly separates itself from primitive creators like create_box/create_shape, but never names a sibling explicitly, so differentiation is left to inference.

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

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

It explains the two ways to source a component, which implicitly tells the agent when to use which parameter (path vs definition). However, there is no guidance on when to choose this tool over create_shape, transform_entities, or list_components, and no mention of prerequisites such as an open model.

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

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

Annotations cover the safety profile (idempotent, non-destructive, non-read-only), and the description adds real behavioral detail beyond them: exactly which files are copied, the target Plugins path, that a restart is required, and that dry_run only reports. This is useful operational context the annotations do not convey.

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, then mechanics, then parameter semantics, then the return note. Dense but nearly every sentence earns its place; the Windows path detail is slightly verbose but justified for a filesystem-writing 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 mutation tool with no output schema, the description covers what it writes, where, the restart requirement, dry-run behavior, and even the returned rbz path. An agent has everything needed to invoke it correctly; only explicit 'when to prefer manual install' guidance is 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 description coverage is 0%, so the description must carry the parameters, and it does: 'Empty versions = every version opened at least once' defines the versions default, and 'dry_run=true only reports what would be done' defines dry_run. Both parameters get meaningful semantics not present in 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+resource ('Install the SU MCP Bridge extension') and the reason ('so the other tools can connect'), which distinguishes it from every sibling (model/entity manipulation tools). An agent can immediately tell this is the setup/bootstrap 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 'so the other tools can connect' clause implies this is a prerequisite when other tools fail, and it clarifies the restart requirement and the dry_run preview path. It does not explicitly state 'call this first if the bridge is not connected,' but 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds that results are sorted descending and that include_groups=true also lists groups, but it does not detail return format or pagination. This level of added context is modest.

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

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

The description is two sentences and front-loads the core action and output format. The use case and parameter note follow efficiently, with no wasted words.

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

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

For a simple read-only listing tool with one optional parameter and no output schema, the description covers purpose, output ordering, use case, and the include_groups behavior. Annotations already handle the safety profile, so remaining gaps are 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?

With 0% schema description coverage for the single optional parameter, the description compensates by explaining that 'include_groups=true also lists groups.' This makes the parameter's effect clear, though it could also state the default (false).

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: 'List component definitions and their instance counts (sorted descending).' It further clarifies the output is sorted and provides a use case ('count equipment/furniture'), which separates it from sibling listing tools like list_tags 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?

The description gives a clear usage context: 'use it to count equipment/furniture.' It does not explicitly name alternatives or when not to use this tool, so it stops short of the top 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the returned field names, which is useful context, but does not describe ordering, pagination, or whether hidden/default materials are included—minor gaps for a simple read-only listing.

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

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

The description is a single front-loaded sentence with no wasted words, and the colon list of return fields is well structured. It is appropriately sized for the tool's simplicity.

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 must carry return-value information; it does this by naming the key fields. It omits details like return shape or ordering, but for a zero-parameter list tool it is largely 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?

The tool takes zero parameters, so the baseline score of 4 applies. The description correctly says nothing about parameters, and no parameter documentation is needed.

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

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

The description uses a specific verb ('List') and resource ('materials') and enumerates the returned fields, so an agent knows exactly what the tool provides. It does not explicitly name or distinguish a sibling such as set_material, which keeps it from 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 only implied: an agent would call this tool to inspect available materials, but there is no explicit when-to-use, when-not-to-use, or alternative mentioned. For a simple list tool the implied context is adequate, but guidance is absent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: it discloses the aggregation semantics that entity counts include entities inside definitions, which is non-obvious and matters for interpreting results.

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

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

One sentence, front-loaded with the action and resource, then the returned fields in the same breath. No filler, no restatement of the tool name.

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

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

With no output schema, the description carries the return-value burden and does name the three fields returned. It does not describe ordering, pagination, or the shape/type of the visibility field or counts, leaving minor gaps for an otherwise simple zero-param 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?

The tool takes zero parameters, so there is nothing for the description to compensate for; baseline 4 applies. The parenthetical clarifying 'tags (layers)' usefully disambiguates the resource vocabulary without any parameter to mis-specify.

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

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

States a clear verb+resource ('List tags') and disambiguates the domain term by equating tags with layers. It also previews the returned fields, but it never explicitly distinguishes itself from sibling read tools like list_components or list_materials, 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 only implied: an agent can infer this is the read-side counterpart to set_tag, but the description gives no when-to-use statement, no prerequisites, and no named alternative. Adequate for a self-evident zero-param lister, but not explicit guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by spelling out the return contents, which matters because there is no output schema to convey what the agent will receive. Not exhaustive (no mention of cost/latency), but a solid contribution beyond annotations.

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

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

A single, front-loaded sentence that identifies the resource first and then the fields. Every clause earns its place; 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?

With no output schema, the description carries the burden of describing return values, and it does so comprehensively by enumerating the reported fields. For a zero-parameter read-only introspection tool it is essentially complete; only minor gaps (units of counts, whether counts are recursive) remain.

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 per the rubric the baseline is 4. There is nothing to disambiguate, and the description correctly adds no parameter narrative.

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

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

States a clear verb+resource (overview of the open model) and enumerates exactly what it reports: path, units, bounding box size, and counts of groups/components/faces/edges/tags/materials/definitions/scenes/selected entities. This implicitly distinguishes it from detail-oriented siblings like list_tags and list_components by delivering counts rather than listings, though it does not name those 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 only implied: an agent infers it should call this to get a snapshot of the model. There is no explicit when-to-use statement and no guidance on choosing it over list_tags, list_components, list_materials, or selection_info. Adequate but with a clear gap.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description only adds '(empty)' and never explains what the destruction applies to — whether the current in-memory model and its unsaved edits are discarded, whether anything is written to disk, or whether the action is undoable.

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

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

A single short sentence with no filler, front-loaded with the verb. It is efficient, though the terse phrasing leaves the '(empty)' parenthetical doing more work than it can support.

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, destructive tool, the description is too thin: an agent cannot tell whether invoking it silently destroys unsaved work or replaces the active document, and there is no output schema or further description to compensate.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no additional parameter meaning is needed or missing.

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 new model') and adds the '(empty)' qualifier, which implicitly separates it from open_model and save_model. It does not name or contrast with those siblings explicitly, so a 5 is not warranted.

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 offers no when-to-use guidance at all: no condition for choosing this over open_model, no prerequisites, and no warning about the destructive nature of starting fresh. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, and the description adds nothing about why opening is destructive (presumably it replaces the current document and discards unsaved work). It also omits any note about path resolution or failure modes. It does not contradict the annotations, but it contributes no behavioral context beyond them.

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

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

One short, front-loaded sentence with no filler. It is appropriately sized, though the brevity comes at the cost of the missing behavioral detail noted elsewhere.

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 document-replacing mutation with a destructive annotation, no output schema, and an undocumented parameter, the description is too thin. An agent cannot tell whether current unsaved work is lost, what path format is required, or what happens on 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 0% and the single parameter carries no description. The mention of a '.skp file' implies the path targets a SketchUp file, which is marginal added meaning, but nothing is said about absolute vs relative paths or validated extensions.

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

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

States a specific verb (open) and resource (.skp file in SketchUp), which is enough to separate it from save_model and new_model by inference. It does not explicitly name which sibling it complements or replaces, so it falls short of a 5.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as new_model or install_sketchup_bridge. An agent must infer that this is the entry point for loading an existing project.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower, and the description still adds value by disclosing return content and a conditional behavior: it 'warns if the bridge is older than the bundled one'. That conditional warning is a genuine behavioral trait not captured by the annotations.

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

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

It is a single sentence, front-loaded with the core action ('Check the connection') before listing return values. The nested parenthetical about the version warning is slightly dense but still earns its place.

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

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

With no output schema, the description carries the burden of describing returns and does so concretely, and annotations handle the safety profile. The only missing element is any routing guidance relative to siblings like model_info, which is minor for a zero-arg diagnostic 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond confirming that no input is required.

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

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

The description states a specific verb and target ('Check the connection to SketchUp') and enumerates exactly what the call returns (SketchUp/Ruby versions, open model name, bridge/MCP server versions). It is clearly a health/diagnostic check, distinct in kind from the data-fetching siblings, but it never names an alternative (e.g. model_info, which also surfaces model identity) to disambiguate.

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

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

There is no explicit guidance on when to call this versus siblings such as model_info, nor any when-not or prerequisites. Usage is only loosely implied by the phrase 'check the connection', leaving the agent to infer that this is a diagnostic/preflight tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the recursive traversal, the unit conventions (m2 one side, m, m3), and notably the inheritance rule that untagged/unpainted entities inherit from their parent group. It stops short of disclosing cost or performance characteristics on large models.

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 outcome, then the measurement list, then the inheritance rule — a logical ordering with no filler sentences. The dense colon-and-parenthetical structure is slightly run-on but every clause carries information.

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

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

With no output schema, the description usefully enumerates the returned metrics and their units, which is exactly what an agent needs to interpret results. Read-only semantics are covered by annotations. The only gap is the undocumented include_hidden parameter.

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

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

Schema coverage is only 33%, so the description must carry more weight. It does add real meaning for group_by ('by tag or material') and selection_only ('or only the selection'), plus the inheritance nuance that affects grouping. The include_hidden parameter is left undocumented in both schema and description, so the compensation is partial.

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 ('Quantity takeoff: walks the whole model recursively and totals by tag or material') and enumerates exactly what is measured (face area, face count, edge length, volume, instance count). This clearly distinguishes it from sibling listing tools like list_tags, list_components, and selection_info, which enumerate rather than aggregate.

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

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

The parenthetical '(or only the selection)' implies the selection_only parameter's purpose and conveys that the default scope is the whole model, which is useful context. However, it never states when an agent should prefer this tool over the sibling listing tools or when to restrict to a selection, so usage is only implied rather than explicit.

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

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

Annotations declare readOnlyHint=false and destructiveHint=true, and the description richly adds context: the whole snippet is one Undo step, returns the last value (inspect) plus puts output, and warns NOT to call start_operation/commit_operation because the bridge already wraps the code. This is exactly the behavioral detail annotations cannot convey.

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 and the primary fallback condition, then dense, high-signal rules. It is long but virtually every sentence is actionable; only minor benefit from tighter grouping into explicit bullets.

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 purpose, safety profile, undo semantics, return values, unit conventions, entity lookup, and known API gotchas (face.normal before pushpull, local vertex coordinates). With no output schema, the description itself explains the return behavior, leaving nothing an agent needs to call it correctly.

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

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

Schema description coverage is 0% for the single 'code' parameter, so the description must compensate. It does explain the semantics of the code content: internal units are inches (use 1000.mm, x.to_mm), end with a value or puts, and the value becomes the return. Strong compensation, though it doesn't formalize the parameter itself beyond content rules.

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

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

States a specific verb and resource ('Run arbitrary Ruby code in SketchUp (Ruby API)') and immediately distinguishes itself from siblings with 'Use it when the other tools are not enough.' An agent can tell this is the escape-hatch tool without inspecting other schemas.

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

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

Explicitly says to use it only when the other tools are not enough, effectively naming the alternative set and the condition that selects this one. Additional rules (find_entity_by_id, check face.normal, local vertex coordinates, no exit) give concrete invocation guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description usefully clarifies exactly what gets destroyed: an empty path overwrites the current file. It does not say what happens if a supplied Save As path already exists, so it stops short of full 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 terse sentences with zero waste; the core action is front-loaded and the empty-path/Save As branch is compactly expressed with a semicolon.

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

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

For a one-parameter mutation tool with no output schema and annotations covering the safety profile, the description says enough to call it correctly. Missing only edge-case behavior such as overwriting an existing Save As target.

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

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

Schema coverage is 0% and the single path parameter has no description in the schema, so the description carries the burden. It explains the exact semantics of empty vs. non-empty path, though it omits path format expectations (absolute vs. relative, extension handling).

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 ('Save the model') that is instantly distinguishable from siblings like open_model, new_model, and export_file. No explicit sibling routing, but the purpose is unambiguous.

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

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

The description defines what the two invocation modes do (empty path = overwrite; path = Save As) but gives no guidance on when to choose saving versus export_file, or when a Save As is preferable. Usage is implied by the parameter branch rather than stated as intent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context not present in the annotations: when a view is supplied, the camera changes only temporarily and the previous view is restored afterwards, which reassures the agent about side effects.

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

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

Two tight sentences with no filler. The core purpose is front-loaded, and the view behavior detail follows immediately after.

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

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

With no output schema, the description correctly states that an image is returned. It covers the main invocation modes, though it omits image format and says nothing about the sizing parameters (max_size default 1024, width/height interaction), which would help an agent call it correctly.

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

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

Schema coverage is 75%, with 'height' undocumented, so the schema carries most of the load (baseline 3). The description adds meaning beyond that by explaining the view parameter's temporary-and-restored camera semantics, which is not captured by the schema's 'Temporary capture view' text.

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

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

The description names a specific verb and resource ('Capture the SketchUp viewport and return the image') and even states the motivation (so Claude can check modelling results). It is immediately clear what the tool produces, though it does not explicitly distinguish itself from siblings like export_png or set_view.

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

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

The phrase 'to check modelling results' implies a usage context, and 'Empty view = keep the current view' clarifies a mode of invocation. However, there is no explicit guidance on when to prefer this over export_png or set_view, so usage is only implied rather than stated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description does not disclose the key behavioral trait beyond those flags: whether selecting replaces or augments the current selection (the 'clear' parameter defaults to true, implying replacement), which matters for an agent chaining tools.

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

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

One compact sentence, front-loaded with the action and resource, with the qualifier in a parenthetical. Nothing is wasted, though the brevity comes at the cost of the missing behavioral detail noted above.

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 state-mutating selection tool with no output schema, the definition is minimally viable but leaves gaps: no return/effect confirmation, no statement about whether the selection persists across tools, and no explanation of the 'clear' parameter's default behavior.

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

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

Schema coverage is only 50%: entity_ids carries its own description, while 'clear' is undocumented in both schema and description. The description adds only 'by id', which merely restates the schema, so it does not compensate for the undocumented parameter.

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

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

Specific verb (select) plus resource (entities) and identifier basis (by id), scoped to SketchUp. It is distinguishable from the sibling selection_info (which reads rather than sets selection), though it never names that sibling as an alternative.

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

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

The parenthetical gives a purpose context ('so the user can see them, or for later tools to use'), which implies when to call it, but there is no explicit when-to-use vs. alternatives, no mention of prerequisite id sources beyond the schema, and no exclusions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context by revealing the returned payload (fields, mm/m2/m3 units) and its role as an id source for mutation tools. It omits what happens with an empty selection or how the limit behaves, but that is a minor gap against the annotation coverage.

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 first front-loads what is returned with explicit units, the second states the practical purpose. 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?

With no output schema, the description carries the return-value burden and does so well by listing fields and units; it also ties the result to edit/delete tools. Missing only edge behavior such as empty selection or limit truncation.

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?

Only one parameter (limit) with 100% schema description coverage, so the schema fully documents it. The description adds nothing about the limit or truncation behavior, making this minimum-viable at the baseline for 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?

Names a specific resource (info on the selected entities) and enumerates the exact fields returned with units, so an agent knows precisely what it gets. It does not explicitly distinguish itself from near-neighbors like model_info or quantity_takeoff, though the note linking ids to edit/delete tools hints at its 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 line 'The ids are used by the edit/delete tools' implies downstream usage, but the description never states when to pick this over quantity_takeoff, list_components, or model_info. Usage is inferable but not spelled out with alternatives 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?

Annotations already declare this is a non-read-only, idempotent, non-destructive write. The description adds behavior annotations do not carry: a missing material is created with the supplied color, while an existing material retains its color unless update_existing=true. It also surfaces the blast radius of recoloring (every entity using that material), which is important given destructiveHint=false.

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 conditional color/update rule immediately after. No filler, and the parentheses efficiently carry the default-selection behavior.

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

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

For a 5-parameter mutation tool with no output schema and 40% schema coverage, the description covers the material/color/update_existing semantics well but says nothing about back_too or what the call returns. Adequate, with a visible gap on one parameter.

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

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

Schema coverage is only 40%, so the description must carry weight, and it does explain the interaction between color, material, and update_existing. However back_too and the exact format of entity_ids/color are left entirely to the schema, which only partially documents 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?

Names a specific verb+resource (apply a material) and the target scope (entity_ids or current selection), which is enough to tell it apart from list_materials and from the analogous set_tag. It stops short of explicitly contrasting itself with sibling setters, so it lands at 4 rather than 5.

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

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

The parenthetical '(entity_ids or the current selection)' implies the two invocation modes and the empty-list default, which is real usage guidance. There is no statement of when not to use it or which sibling to prefer for related operations, so usage is only implied.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), lowering the bar. The description adds one genuinely useful behavioral fact beyond them: a missing tag is created on demand (upsert). It does not say whether existing tag assignments on entities are replaced, whether a model must be open, or what is returned.

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

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

Two short, front-loaded sentences with no filler: the action and its target come first, the parameter resolution hint second. Every clause carries information.

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

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

For a 2-parameter mutation with no output schema, the description covers the main operation and the create-if-missing side effect, which is adequate. It still leaves gaps an agent would care about: whether existing tags are overwritten, session/model preconditions, and no mention of the result shape.

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

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

Schema coverage is only 50% (entity_ids is documented, tag is not), so the description must compensate — and it does. 'Assign a tag ... A missing tag is created' clarifies that the tag argument is a name string that need not pre-exist, and 'entity_ids or the current selection' reinforces the empty/omitted behavior of the id list.

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 (assign) and resource (tag) plus the target (entities), clearly distinguishing it from the read-only sibling list_tags. It stops short of naming an alternative tool or explicitly contrasting with set_material, so it is clear but not sibling-differentiated at the top level.

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

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

Usage is implied: it explains that targets come from entity_ids or the current selection, which hints at the calling context (including omitting ids to act on the selection). There is no explicit when-to-use/when-not guidance or pointer to alternatives such as list_tags for reading tags.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), lowering the bar. The description adds genuinely useful behavior: iso gives perspective projection while other views give parallel projection. It does not clarify that only camera state changes (not model data) or what happens on subsequent calls, so the added context is partial.

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

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

Two short sentences, zero waste, with the core action front-loaded before the projection nuance. 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 small 3-parameter camera tool with no output schema, the description is nearly adequate, but with 0% schema coverage one parameter is left undefined and the mutation semantics (view-state-only, non-destructive) rest entirely on annotations.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains the view enum's projection behavior and names zoom_extents, but the perspective boolean/null parameter is only obliquely implied ('iso defaults to perspective') and never explicitly defined as an override or how null behaves.

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: 'Set a standard view and zoom extents.' An agent immediately knows this manipulates the camera/viewport rather than model geometry. It does not explicitly contrast with siblings like screenshot or export_png, but the camera-vs-output distinction is inferable from the wording.

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 – you call this when you want to orient the view to a standard direction and fit the model. There is no explicit when-to-use, no prerequisites (e.g. a model must be open), and no mention of alternatives, so guidance is only implied.

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

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

Annotations declare a non-read-only, non-destructive mutation; the description adds value beyond that by disclosing the application order (scale -> rotate -> translate), units (mm, degrees) and defaults. It does not mention undo/rollback availability, which would fully round out the mutation profile.

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

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

Three dense sentences with the operation list front-loaded, then selector semantics, then parameter details and order. 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?

No output schema, six parameters and a mutation tool, so the description carries significant burden and mostly meets it (units, defaults, ordering, selection fallback). Missing only return/undo expectations and a note that pivot defaults to the FIRST entity's center.

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, but the description adds meaning beyond the schema: translate is explicitly a relative offset, rotate is counterclockwise viewed from axis tip, and the ordering of the three operations clarifies how the interacting parameters compose.

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 entities') that no sibling duplicates. An agent can immediately tell this is the geometric transform tool versus deletion, selection, or creation tools.

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

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

It clarifies that empty entity_ids falls back to the current selection, which is useful invocation context, but it never states when to use this tool versus alternatives (e.g. select_entities first) or any 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state irreversibly. The parenthetical adds genuinely useful behavioral context about undo granularity (one tool call = one step), but the description says nothing about what happens when the undo stack is empty or whether the call fails or silently no-ops.

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

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

A single front-loaded sentence with zero waste, where the parenthetical carries real information rather than padding.

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, annotated mutation tool with no output schema, the description covers purpose, granularity, and the implicit mutating nature. The only gap is empty-stack / failure behavior, which is a minor omission given how little an agent needs to invoke this 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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter syntax an agent could get wrong and nothing the description needs to compensate for.

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

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

States a specific verb (undo) and its exact scope (the last step in SketchUp), and the parenthetical nails the granularity of that step. No sibling in the list competes with it, so no differentiation is needed, but the description itself makes no such routing explicit.

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

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

There is no undo/redo alternative among the siblings to route between, and the parenthetical implies use after any model-editing call, but the description never states when to invoke it or what condition (e.g. nothing left to undo) makes it inappropriate.

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