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

Annotations only declare it is a non-read-only, non-destructive, closed-world call; the description adds substantial behavior beyond that — update-by-name semantics that preserve omitted settings and never copy, new-light defaults (spot, 1000 W, [0,0,3] pointing down), and a refusal rule for bl_light_ names. This is exactly the extra context annotations cannot carry.

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?

Dense but nearly every sentence carries parameter or behavior information that is otherwise unavailable at 0% schema coverage. It is front-loaded with the create/update distinction, though the long unstructured paragraph could be easier to scan as a parameter list.

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

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

For a 13-parameter, zero-coverage mutation tool with no output schema and only thin annotations, the description supplies defaults, units, per-kind constraints, naming restrictions, and update semantics. Nothing an agent needs to invoke it correctly appears to be missing.

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

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

Schema description coverage is 0% across 13 parameters, so the description must compensate and it does: units for location/look_at, wattage semantics including the W/m2 sun case and exposure guidance, color formats, temperature_k range, cone angle and blend ranges, cutoff_m, radius vs size, and shadow_soft are all explained.

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

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

States a precise verb+resource ('Create or update one light') and immediately distinguishes itself from setup_lighting, which makes whole presets. An agent can tell add_light apart from the lighting siblings without opening a schema.

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

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

Explicitly routes to setup_lighting for presets and to delete for removal, and states the bl_light_ name restriction. It does not say how to discover existing light names (e.g. list_lights) or what to do when several lights are needed, so the when-to-use picture is clear but not exhaustive.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the mutation risk is declared. The description adds real behavioral detail beyond that: shared meshes are made single-user first, children retain their world position, and mirrored negative scale is handled without flipped normals. It stops short of saying whether the bake is undoable or what it returns.

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

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

Three tightly packed sentences with the core purpose front-loaded and the Ctrl+A reference immediately orienting the reader. Slightly dense, but every clause carries distinct information about edge-case handling.

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 and annotations covering the safety profile, the description supplies the edge-case behaviors (single-user meshes, child placement, mirrored scale) an agent needs. It omits mode enumeration details and any mode/selection prerequisites, but is broadly sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden, yet it only expands on `mode: all` (origin goes to world origin) and never explains `scale` or `scale_rotation`, nor the `names` array. Partial compensation gives a baseline 3.

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

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

States a specific verb+resource ('Bake the transform of meshes into their vertices') and anchors it to a familiar operator ('as Ctrl+A does'). It does not distinguish itself from nearby siblings such as transform_objects or set_origin, which apply or move transforms rather than baking them.

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

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

There is no statement of when to use this tool versus transform_objects, set_origin, or transform_region, and no preconditions (object mode, selection requirements, undo behavior). The Ctrl+A analogy implies familiar Blender usage but no actual routing guidance is given.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds useful context by saying copies are merged into one mesh (i.e., the result is a single combined object rather than separate instances), but it stays silent on whether the source object is consumed or preserved, which is a material detail for a destructive operation.

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

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

Two short sentences with the core action front-loaded and no filler. The trailing example list is efficient but reads as a verbless fragment, which is mildly cryptic rather than wasteful.

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 5 parameters, 0% schema description coverage, and no output schema, the description leaves significant gaps for an agent: keep_source behavior, the role of `name`, and the fate of the source object are never addressed. The core operation is clear, but not enough is disclosed to call 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 description coverage is 0%, so the description must carry the load, and it only partially does: it defines `count` (times to repeat) and `offset` (world vector, step in metres). The `object`, `name`, and especially `keep_source` parameters — the latter directly tied to the destructive annotation — receive no explanation anywhere.

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

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

The description gives a specific verb+resource ('repeat an object count times ... merge copies into one mesh') that an agent can act on, and the 'along the world vector offset' phrasing implicitly separates it from the sibling radial_array. It does not explicitly name radial_array/duplicate/mirror, so sibling differentiation is inferential rather than stated.

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

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

Usage is only implied via the trailing examples ('Fences, stairs, windows, planks, teeth'), which sketch realistic use cases but give no when-to-use rule or comparison to radial_array, duplicate, or mirror. There is no statement of when NOT to use it or what alternative to pick for radial/circular repetition.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: a failure returns 'actual', 'expected' and a 'fix' tool, and a bad check or missing object is reported as an 'error' while the remaining checks still run. Error-isolation and response shape are disclosed; rate/permission behavior is not applicable here.

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

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

Front-loaded with the purpose and workflow in the first two sentences, followed by a dense but necessary reference list of check types. Every line documents a distinct check, so the length is earned, though the block is heavy enough that some structure loss is unavoidable.

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 explain return values, and it does: pass or fail with real numbers, failure objects containing actual/expected/fix, and error reporting for invalid checks or missing objects. For a single-parameter, high-complexity validation tool this is complete.

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

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

Schema coverage is 0% and the schema is a generic array of open objects, so the description carries the full burden. It does so thoroughly, documenting every check type with its fields, units (world size in metres, distance, max_depth, margin, tolerance, max_unmatched_share), and semantics such as 'connected' meaning touching or overlapping and gap being 0 on overlap.

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: it runs a set of declarative assertions against the model and returns pass/fail with actual numbers. The enumeration of check types (size, position, ratio, gap, contact, symmetry, inside, on_ground, clean, budget, connected) makes it unmistakable against siblings like check_mesh, check_symmetry, check_contacts, and check_game_ready, which each cover a subset.

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

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

Gives clear workflow guidance: state expectations before looking at the result, then fix only the failures, and use one call for all checks. That implicitly routes the agent here instead of the single-purpose check_* siblings, but it never explicitly names an alternative or an exclusion condition, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, so mutation is known; the description adds non-obvious cost behavior (one draw call per material in-engine) and the slot-auto-creation side effect, both beyond annotations. It does not disclose what happens to the overwritten faces' prior material assignment or error behavior for a missing material.

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?

Dense but front-loaded: purpose first, then cost caveat, then the where grammar. Slightly redundant — 'the other faces keep theirs' and 'Other faces keep their material' restate the same fact in adjacent sentences.

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 3-param mutation tool with no output schema and no meaningful schema descriptions, the description covers the what, the prerequisite chain, the selection grammar, and the performance consequence. An agent has everything needed 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 coverage is 0% and `where` is an opaque open object, so the description must carry the burden — and it does, enumerating all supported keys (normal, angle, x/y/z, box, area, index) with defaults and the {} / null meaning. The `object` and `material` parameters are only implicitly explained (name strings, material must already exist), leaving some ambiguity about accepted identifier formats.

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 (put/assign) and resource (material on picked faces) with the exact scope: picked faces get it, others keep theirs, slot added if needed. This is clearly separable from sibling set_material, which is explicitly named as the prerequisite for creation rather than assignment.

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 real workflow sequencing: create the material first with set_material, and inspect mesh_info before picking faces. That is genuine when-to-use guidance, though it never states when NOT to use it or what to do if the material does not exist on the object.

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 (destructiveHint=true) already flag that this mutates the scene, and the description adds real context beyond that: the default places part on top, child boxes are included, with_children=false measures objects alone while children still move, and it names the return fields (`boxes_used`, `moved_by`). It stops short of stating explicitly that the part's existing placement is overwritten, so not a full 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?

Purpose is front-loaded in the first clause, and each following sentence adds constraints, anchor format, or return shape rather than filler. It is dense and slightly blocky but nothing is wasted.

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

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

No output schema exists, yet the description explains the return payload (`boxes_used` with objects/min/max/size, `moved_by`, top-level min/max being of `part` alone). Combined with the defaults, anchor semantics, and surface limitations, an agent has everything needed to invoke it correctly.

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

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

Schema coverage is 0%, so the description carries the full burden and does so: anchors are explained as fractions 0..1 per axis with concrete examples ('(0.5,0.5,0)' bottom centre, '(0.5,0.5,1)' top centre), `offset` is stated to be in metres, and `with_children` semantics are spelled out. Every non-obvious parameter is decoded.

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 with the exact mechanism: 'move `part` (with its children) so an anchor of its world box lands on an anchor of the box of `to`'. It also distinguishes itself from siblings by naming move_to_contact, place_on, and transform_objects as the routes for surface-aware or known-offset moves.

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 covers when NOT to use it and why: 'Surfaces are not looked at', 'Boxes do not follow round or slanted surfaces', and directs the agent to move_to_contact for real gaps, place_on for uneven ground, and transform_objects for a known offset. Alternative selection is fully resolved.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false; the description adds substantial behavioral context: Cycles CPU, background job with one map per step, 20–60 s timing, job_status polling, cancel behavior, and the warning not to edit the object while running. 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?

Long but justified by 10 undocumented parameters and a multi-step job workflow. The first sentence front-loads purpose, and every following sentence supplies needed operational or parameter detail 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?

Complete for a destructive, background-job baking tool with no output schema: it covers prerequisites (UV map), job return via job_status, material replacement effects on export_glb, and edge cases like flat normal maps. 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 coverage is 0%, so the description must carry parameter meaning. It explains all ten parameters, including map choices and defaults, output naming and out_dir fallback, size recommendations, margin, samples, bevel_radius constraints, UV layer selection, and replace_material 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?

States a specific verb (bake) and resource (material of one mesh into PNG maps on its UV), and ties the purpose to glTF carrying procedural or layered materials. It distinguishes itself from material-creation siblings by being the baking step.

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 context, including that export_glb writes the textures when replace_material is true, and gives map-selection guidance for metals and occlusion. However, it does not explicitly name when to choose it over siblings like procedural_material or set_material, nor when not to use it.

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

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

Despite annotations already flagging destructiveHint=true, the description adds substantial behavioral context: clamping of overlapping bevels, the 'one tight edge limits every bevel' rule, the returned fields (achieved_width, clamped, warning), and post-processing that removes doubled vertices and zero-area faces. This goes well beyond the annotation layer.

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 is front-loaded and every sentence carries technical information (defaults, return fields, cleanup). It is dense and runs long as a single block, but there is little wasted wording.

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 mesh-mutation tool with no output schema, the description supplies return-value semantics and clamping/warning behavior, which is exactly what an agent needs. Coverage of the remaining width_type enum values is the only notable omission.

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, the description carries the burden and does so well: it defines width units and default, segments (1=chamfer, 3=round), profile (0.5=circular), width_type 'width' semantics, and where as x/y/z ranges and box. It omits the other enum values (offset, depth, percent, absolute), leaving a small gap.

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

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

The opening clause names a specific verb and resource: 'Round or chamfer the edges sharper than `angle` degrees', which uniquely identifies a bevel operation. It does not name any sibling (e.g. weld, subdivide, extrude_faces) to disambiguate, so it is clear but stops short of explicit sibling differentiation.

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

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

Usage conditions are implied through constraints ('Only edges with two faces can be bevelled', angle threshold, optional `where` filter) rather than stated as when-to-use guidance. There is no explicit statement of when to prefer this over alternatives like subdivide or inset_faces.

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

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

Annotations declare destructiveHint=true but say nothing about what is destroyed; the description supplies that by stating existing same-named groups are overwritten. It also discloses the auto→proximity fallback and the relative performance of each method. It still doesn't state permission/context requirements or whether non-matching groups are preserved.

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 action, then the concrete effects, then method trade-offs, then overwrite semantics, then workflow pointers. Dense but each clause adds information; the parenthetical semicolon style is slightly heavy but not wasteful.

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

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

For a destructive, no-output-schema tool this covers the essential agent needs: what it mutates, what it overwrites, method choice, and how to verify the result. Missing only finer details such as context/selection requirements and treatment of pre-existing groups that don't share bone names.

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

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

Schema coverage is 0%, so the description carries the burden, and it meaningfully explains three of five parameters: the two method enum values with their trade-offs, max_influences as the influence cap, and falloff as a power exponent. 'meshes' and 'armature' are only implied by the opening sentence rather than defined (e.g. name references), leaving a small gap.

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

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

Opens with a specific verb+resource ('Skin meshes to an armature') and immediately enumerates the concrete effects (vertex group per bone, Armature modifier, parent). This distinguishes it from siblings like parent, attach, and transfer_weights, which an agent could otherwise confuse it with.

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 method-selection guidance with conditions: 'proximity' for fast/stylised low-poly, 'auto' for clean meshes with a proximity fallback. It also routes the agent downstream ('Check with check_weights, then try poses with pose_sheet'). No explicit when-not-to-use or prerequisites (e.g. selection/context requirements) are stated, so it stops short of a 5.

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

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

Annotations already declare destructiveHint=true and that this is not a read-only or open-world operation. The description goes beyond them by explaining what the destruction actually is: 'clear' discards one side of the cut, the discarded inner side is defined as the negative side of the axis, and 'fill' closes the resulting cut. It does not address reversibility/undo or mesh prerequisites, which keeps it short of 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 dense sentences with the core operation front-loaded, followed by parameter behavior, then use cases. Nothing is repeated from the schema or annotations and no sentence 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?

For a five-parameter destructive mesh edit with no output schema and annotation-only safety hints, this covers the operation, the parameter conventions, and intended uses well. Minor gaps remain around prerequisites (e.g. whether the object must be manifold or selected) and undo expectations.

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

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

Schema description coverage is 0%, so the description must carry the parameters and largely does: it explains 'axis' and 'at' as the cutting plane, 'clear' as inner/outer removal with the convention that inner = negative side of the axis, and 'fill' as closing the cut. Only the required 'object' parameter is left unexplained, which is near-universal for this toolset.

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

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

States a concrete verb and resource ('Cut the mesh with a world plane') and pins the operation down with a useful analogy ('like a loop cut placed in metres') plus the exact axis/coordinate it acts on. It does not explicitly contrast itself with nearby siblings like boolean, subdivide, or mirror, but the operation is unmistakable.

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 final sentence gives three concrete use cases: slice, add a loop for later extrusion, or trim a part flat. There is no explicit when-not guidance or named alternative (e.g. when to prefer boolean or a face-based cut over a world-plane cut), so it stops short of full routing guidance.

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

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

Annotations already declare non-readOnly, non-destructive, non-openWorld, so safety is covered; the description adds real behavioral context about how overlapping balls blend and how radii interact with the resulting surface. It does not say that a new object is created, how it is named, or what resolution/threshold do to output density.

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

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

Three tight sentences, front-loaded with the technique, then use cases, then the one non-obvious parameter rule. Nothing is padding and the sizing advice is actionable.

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

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

A five-parameter generative tool with no output schema and no schema descriptions needs more than this: the effect of threshold and resolution on the result is never explained, and the description never states what is produced (a new named object) or whether it replaces existing geometry.

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

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

Schema description coverage is 0%, so the description carries the full burden. It usefully clarifies that radii is one value per point (the key mapping between the two parallel arrays), but leaves name, threshold, and resolution — the latter two defaulting to 0.6 and 0.05 with no explanation of their effect on the mesh — entirely undocumented.

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

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

States a specific verb and resource ("make one smooth organic mesh from overlapping balls (metaballs)") and explains the defining mechanic: the balls merge into a single skin. It clearly separates itself from hard-surface siblings like create_primitive or loft by naming the metaball technique, though it never names a 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?

Gives concrete when-to-use context ("Good for hands, clouds, bushes, rocks, creature bodies") plus a practical sizing rule ("use radii a bit larger than the surface you want"). It stops short of when-not-to-use or pointing to an alternative tool for hard-surface or single-primitive work.

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?

Beyond the destructiveHint annotation, the description discloses substantial behavior: repair/repair_mesh healing, exact failure conditions and what they report, solver fallback logic including a micrometre tool shift, material slot inheritance rules, welding and zero-area face dissolution, and the allow_open override with a warning. This is a model of behavioral disclosure for a mutation 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?

Dense and long, but front-loaded with the core action and every sentence carries distinct information (failure modes, returned fields, materials). Slight over-density but appropriate for a tool with this many interacting behaviors.

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 7-parameter, no-output-schema tool: it even names the answer fields (repaired, merged_vertices, removed_zero_faces, doubled_vertices_left, solver, tool_shift_m), covers failure paths, and closes the loop on both input preconditions and result validation.

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

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

Schema coverage is 0%, so the description carries the full burden and does so well: it explains keep_tool, repair, allow_open, the solver fallback, and operation ('difference' is spelled out, union/intersect implied by the enum). The enum values EXACT/MANIFOLD/FLOAT themselves are not individually defined, but their selection mechanism is described.

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 ('Combine two meshes') and explains the transformation precisely: `a` is changed, `b` is the tool and deleted unless keep_tool, and difference cuts b out of a. However, it never differentiates itself from the sibling `combine` tool, leaving ambiguity about which to pick for merging meshes.

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

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

Gives clear application context ('Use it for windows, doors, holes, notches') and states the key precondition that both meshes should be closed with outward normals (check_mesh). It stops short of naming alternatives or when-not to use it, e.g. versus `combine`.

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, openWorldHint=false, so the safety profile is covered. The description adds real behavioral context: the exact named meshes/empties produced, the coordinate orientation, and the door/cover height semantics. It does not say whether same-named objects are overwritten or how the operation fails, which keeps 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?

Front-loaded with the core purpose, then packed with necessary encoding details; almost every clause adds usable information. It runs long and the unit guidance ('cell metres') arrives last as an addendum, but there is little outright 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?

For a 10-parameter, no-output-schema creation tool, this covers input encoding, produced artifacts, and downstream verification adequately. The unmentioned origin/floor_thickness/wall_height parameters are the only real gap for correct invocation.

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

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

Schema coverage is 0%, so the description must carry the burden and largely does: it explains layout format, legend structure with kinds, cell units, and ties cover_height/cover_fill/door_height to the 'C' and 'D' characters. However, origin, floor_thickness, and wall_height (as distinct from per-legend height) are never mentioned, leaving part of the 10-param surface undocumented.

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

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

States a specific verb and resource ('Block out a level from a text plan') and immediately pins down the input format (one string per row, row 0 at top/+Y, column 0 at left). The character legend and output artifacts ({name}_floor, {name}_walls, {name}_cover, {name}_spawn_1) make it unmistakably distinct from generic siblings like create_primitive or terrain.

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 routes the agent to verification tools ('prove it with walkable_map, route, check_passages, sightline_map') and gives a selection heuristic for cell size ('1 for rooms, 0.5 for detail'). It lacks any when-not-to-use or comparison against alternative level-blocking siblings, so it stops short of 5.

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

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

Annotations already declare a safe read-only, closed-world operation, and the description adds genuinely useful behavioral detail beyond them: the exact states returned and, for overlaps, the deep-sample/median-depth/inside-share metrics with an illustrative donut-glaze example. It stops short of noting performance or mesh-validity prerequisites, but the output semantics are unusually well disclosed.

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 state definitions are front-loaded and the two sentences carry no filler; the donut example earns its place by clarifying a non-obvious metric. Density is high but 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?

With no output schema, the description usefully explains the returned states and overlap metrics, covering the return-value gap. It still leaves the parameters undefined and mirrors the floating-parts use case of a sibling (find_floating) without disambiguating, so an agent has enough to try the call but not to call it confidently.

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 two required parameters are named only 'a' and 'b'. The description's phrase 'two meshes' indirectly implies they are mesh identifiers, but it never states that a and b are mesh names/IDs, their format, or their ordering effect. The parameter gap is largely uncompensated.

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 operation on a concrete resource: reporting the contact state (intersecting/touching/apart) between exactly two meshes, including depth metrics. It is clearly distinguishable from most siblings, though it never explicitly contrasts itself with closely related tools like check_mesh, measure or find_floating.

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 gives one concrete use case ('find floating or sunken parts'), which is real usage guidance. However, it names no alternatives (e.g. find_floating, line_of_sight, check_mesh) and states no when-not-to-use conditions, so routing among similar siblings 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?

Annotations only establish read-only/non-destructive/no-open-world, and the description goes well beyond that: it distinguishes errors from warnings, states that `ready` is true only with zero errors, explains that a boolean cutter without a material leaves faces behind, warns that near-symmetry faults are invisible in silhouette, and notes symmetry_axis=null skips the check. It also discloses the instancing/draw-call economics that budget_only reports. This is rich behavioral context the annotations cannot supply.

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 errors, then warnings, then the budget_only mode — a logical order with no filler sentences. It is dense and slightly long as a single block, which costs it a point, but every clause maps to an actual check or parameter.

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 tool with no output schema, the description covers the validation taxonomy, the `ready` flag semantics, and two output fields (over_budget, draw_calls_if_instanced) plus the instancing hint. Some parameter defaults and the remainder of the return payload are left implicit, so it is nearly but not fully complete.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does map most parameters to meaning: names, the `max_*` budget limits, max_texture ('oversized textures'), max_materials ('many/empty material slots'), require_uv ('missing UV'), name_pattern ('bad names'), and symmetry_axis including the null-skip behavior. It does not individually disambiguate max_tris vs max_objects vs max_draw_calls or explain default values, so it is strong but not complete.

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

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

Opens with a concrete framing ('Pre-export gate') and then enumerates the exact error and warning categories checked, so an agent knows precisely what class of validation this performs. It clearly separates itself from mesh-level siblings like check_mesh through the export-readiness framing. It never names a sibling, so it stops short of the explicit differentiation a 5 requires.

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?

'Pre-export gate' establishes the primary call site, and the budget_only paragraph explicitly states it is 'the cheap budget question at any stage', giving a clear when-to-use rule for the fast mode. There is no explicit statement of when NOT to call it or which sibling to prefer for narrower checks (e.g. check_symmetry, check_mesh).

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds valuable output semantics beyond the annotations: it explains that 'issues' is ['none'] when the mesh is clean and defines the UV quality fields, including the texel_density_spread threshold where above 4 means stretched.

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

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

The description is front-loaded with the diagnostic list, followed by concise explanations of the 'issues' and 'uv' fields. Every sentence adds useful information, with no filler or repetition.

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

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

There is no output schema, so the description must explain return values; it does so for 'issues' and the UV map fields but not for the full return structure, such as counts, arrays of holes, or loose parts. It also leaves the required 'name' parameter unexplained and provides no usage context, making it only minimally complete for an agent to invoke it correctly.

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

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

The schema has one required parameter, 'name', with 0% description coverage, and the description never mentions or explains it. With low schema coverage, the description is expected to compensate, but it provides no information about what the name refers to or how to supply it.

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 that the tool reports mesh diagnostics: triangle/n-gon counts, open holes, loose parts, zero-area faces, doubled vertices, inward normals, unapplied scale, and UV quality. It distinguishes itself from generic mesh-info siblings by focusing on quality issues and UV metrics, but it never explicitly says how it differs from tools like mesh_info or check_game_ready.

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 tool versus alternatives such as mesh_info, check_game_ready, or repair_mesh. The implied use case—validating a mesh—is inferable from the name and output list, but the description provides no when-to-use, when-not-to-use, or routing guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and a closed world, so safety is covered. The description adds real behavioral value beyond that: width is measured as free width including agent radius, accuracy is 'about one cell', and the error 'errs on the small side' — a conservative bias an agent must know when interpreting pass/fail. It also discloses the return shape ('violations with positions and a map').

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 purpose is front-loaded in the first sentence, and the following sentences each add a distinct fact (classification rule, measurement semantics, accuracy, return shape, level selection). It is dense but nearly every clause earns its place; the run-on middle sentence is the only mild structural wrinkle.

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 read-only analysis tool with no output schema, the description covers what an agent needs to call and interpret it: the measurement definition, the conservative error direction, and the returned artifacts. Minor gaps remain around 'names' and 'agent_height' and around cost/scale on large levels, but nothing essential for 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 description coverage is 0% across 8 parameters, so the description must carry the load, and it does substantially: it defines min_door, min_corridor, door_length, the role of start, and implies agent_radius ('including the agent radius') and cell ('accurate to about one cell'). Only 'names' and 'agent_height' are left undefined, so it compensates well but not completely.

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

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

States a specific verb and resource — 'Find doorways and corridors of a level that are too narrow' — and defines the check precisely (narrow runs along the walkable centre line, doorway vs corridor classification). It is clearly distinguishable from siblings like walkable_map, route, and line_of_sight, which deal with reachability rather than narrowness.

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

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

Usage is implied rather than stated: the tool is evidently a navigation-clearance validator, but the description never says when to prefer it over walkable_map, check_game_ready, or measure, nor does it state prerequisites such as needing geometry already built. The mention that 'start' picks the area 'when there are several levels' is the only contextual trigger offered.

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 readOnlyHint=false (a write), destructiveHint=false, and openWorldHint=false. The description adds non-obvious scope semantics beyond those annotations: checkpoints are bound to the open file and are not visible to a new or different file. It still doesn't disclose overwrite behavior for the default name.

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

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

Two compact sentences with the core action front-loaded. The second sentence is longer than strictly necessary but carries genuinely useful scoping information rather than filler.

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

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

For a one-parameter write tool with annotations covering the safety profile and no output schema, the definition covers purpose and persistence scope but omits when to use it relative to rollback and the meaning of the name argument. 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 description coverage is 0% for the single 'name' parameter. The description's word 'named' hints that the argument labels the checkpoint, but it does not explain the default value 'last' or what naming implies (e.g., overwriting an existing checkpoint), so it only partially compensates.

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

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

States a specific verb and resource: 'Save the scene as a named restore point.' An agent can understand what it produces, but the description never names or contrasts with the obvious sibling (rollback), 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?

There is no explicit when-to-use guidance and no mention of alternatives such as rollback or save_blend. The only context is a note about file scoping, which describes behavior rather than when to invoke the tool.

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

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

Annotations already establish read-only, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value by disclosing the default for `at` (bbox middle) and a context-dependent default for `tolerance` (0.005 m for objects >= 0.3 m, smaller for small ones) and noting the result echoes the value used.

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

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

Three tight sentences, front-loaded with the core operation, then the two parameter defaults. Every sentence earns its place; only the somewhat compressed backtick phrasing slightly slows reading.

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 tool with no output schema, the description covers the trickiest defaults but leaves `axis` semantics, the relationship between `axis` and `at`, and any detail of the returned answer unspecified beyond one clause.

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

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

Schema description coverage is 0%, so the description carries the burden. It covers `at` and `tolerance` defaults well, but `axis` (the enum that `at` is measured along) is never mentioned, and `names` is only obliquely referenced as 'the objects'.

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 operation (mirror vertices across a plane and count unmatched ones), which is precise enough to reveal that this is a symmetry analysis rather than a geometry edit. It does not explicitly differentiate itself from the sibling `mirror` tool, which an agent could easily confuse it with given the shared 'mirror' 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 by the name and the counting semantics, but there is no statement of when to use this versus `mirror`, `check_mesh`, or `check_contacts`. No exclusions or prerequisites are given.

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

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

Annotations already declare this as a safe, read-only, closed-world operation, so the safety profile is covered. The description adds genuine value by listing the failure conditions it detects, but says nothing about what the result looks like (report, list of offending vertices, pass/fail) or how severe each finding is, which matters for a tool with no output schema.

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

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

A single front-loaded fragment beginning with 'Skin quality:' followed by a tight list of checks. Every clause carries information and nothing is padded, though the sentence fragment style is less readable than a complete sentence would be.

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

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

For a two-parameter read-only diagnostic with no output schema, the description covers what is checked but not what the agent receives or what to do next. Given sibling tools like transfer_weights, bind, and repair_mesh exist, a hint about remediation after a failed check would round it out.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains max_influences indirectly by noting the glTF target of 4 bones, which clarifies the threshold's purpose, but the required 'mesh' parameter is not described at all (e.g., whether it takes an object name or a mesh datablock).

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 resource (skin weights) and enumerates exactly what is inspected: unweighted vertices, excess bone influences, non-normalized weights, orphan vertex groups, and a missing Armature modifier. That is far more concrete than a generic 'check' tool, though it never names how it differs from nearby diagnostics like check_mesh or check_game_ready.

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 statement and no named alternative. The parenthetical 'glTF wants 4' faintly implies a pre-export validation context, but the agent is left to infer that this is a pre-export or post-bind quality gate rather than being told.

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 openWorldHint=false, so the safety profile is covered. The description adds real behavioral facts beyond them: the merge happens in world space, materials are preserved, and geometry is neither welded nor moved. It omits, however, that source objects are removed by default (delete_sources=true), which is the concrete destructive consequence.

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

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

Three tight sentences, front-loaded with the core operation, followed by motivation and the key semantic caveat. No filler or repetition.

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 should carry more weight. It covers purpose, timing, and geometry semantics well, but leaves the fate of the source objects (default deletion) and the naming of the result unexplained — significant omissions for a destructive mutation tool.

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

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

Schema description coverage is 0% and the description says nothing about any of the three parameters. It never explains that `names` is the list of objects to merge, what `name` does (output object naming), or — most importantly — that `delete_sources` defaults to true and destroys the originals. With zero schema documentation, the description needed to carry this load and does not.

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

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

States a specific verb and resource ('Merge several meshes into one mesh object') and anchors it to a familiar reference behavior ('as Join (Ctrl+J) does in Blender'). It also contrasts the operation with siblings by clarifying it is not welding (vs `weld`) and not a positioning op (vs `move_to_contact`).

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 when-to-use rule ('Do it before export to save draw calls') and routes a related need to an alternative ('use move_to_contact to close a gap'). It stops short of naming when NOT to combine, e.g. when separate objects are still needed downstream (vs `attach`/`parent`), but the guidance is clearly actionable.

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 mark it readOnly/non-destructive, and the description goes well beyond them: it enumerates return values (iou_registered, both sizes, per-band table with verdicts, inner_detail edge_agreement), explains the sub-0.3 IoU hint, the empty-`names` behavior listing a huge floor/backdrop in `excluded`, and that `out` writes the composite image. That is rich behavioral disclosure the annotations cannot carry.

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?

Nearly every sentence carries non-redundant information, but it is delivered as one dense run-on paragraph with no headers or bullets, forcing the agent to parse view-by-view orientation details mixed with return-value notes. Appropriately sized for a 12-parameter tool, but poorly structured for front-loaded scanning.

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

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

For a complex 12-parameter tool with no output schema, the description covers the interaction model, scale semantics, view conventions, output payload, and side effects of `out`, which is close to sufficient. Gaps remain on size, bands, and threshold semantics.

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

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

With 0% schema description coverage the description must do the work, and it explains view (with per-view axis orientation), flip/rotate ordering, height_m vs width_m semantics, names, colors, and out in real detail. It leaves size, bands, and threshold unexplained, so it compensates for most but not all of the 12 parameters.

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

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

States a specific verb+resource+scope: comparing a model against a reference image in a single flat orthographic view, and calls out that it produces the main build-from-references metric. It also separates itself from neighbors, explicitly routing perspective photos to match_camera and overlay_reference, so an agent can distinguish it from fit_to_reference/overlay_reference without opening a schema.

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

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

Gives a clear alternative route ('For a perspective photo use match_camera and overlay_reference') and conditions for the scale parameters (give height_m/width_m to catch a size mismatch, omit both to compare shape-only). It lacks an explicit when-not-to-use statement or a direct comparison to the closer sibling fit_to_reference.

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

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

Annotations already declare it is a non-destructive, non-open-world write. The description adds real behavioral context beyond that: bones are in world metres and parents must be listed before children, an ordering constraint that will cause failures if violated. It does not say what happens on name collision 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?

Purpose is front-loaded in the first sentence, but the bones schema is rendered with stray quotes and mid-sentence line breaks, making the spec harder to parse than it needs to be. Content mostly earns its place, but the formatting is sloppy.

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

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

For a two-parameter creation tool with annotations covering the safety profile and no output schema, the description covers the input format, ordering requirement, and follow-up workflow. Missing only the armature 'name' semantics and error/collision 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 0% and the bones array is an untyped object with additionalProperties, so the schema documents nothing. The description compensates by enumerating the exact item keys (name, head, tail, parent, connect) and units, which is substantial added meaning; only the top-level 'name' parameter is left unexplained.

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

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

States a concrete verb and resource: make a skeleton (armature) from numeric bone data. An agent can distinguish it from mesh-creation siblings like create_primitive or limb, though it never explicitly contrasts itself with limb or list_bones.

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 clear workflow: create the armature, then 'bind a mesh with bind, and test with pose', naming the two sibling tools that follow this one. It does not state when NOT to use it or prerequisites (e.g. mesh must already exist), so it stops short of a 5.

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

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

Annotations already declare the write/non-destructive/non-open-world profile, so the bar is lower, and the description adds real context beyond that: size is in metres with no hidden scale, anchor is a fraction of the bounding box placed at the world point, rotation order is world X then Y then Z about 'at', and size is pre-rotation. It also hints at the return ('the size and box after the turn'). It doesn't cover failure modes or permission needs, keeping it below 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?

The text is dense and front-loaded, leading with the core sizing constraint and then unpacking anchor, size, and rotation in logical order. Every sentence carries geometric information, though the run-on style (multiple concepts per sentence) slightly reduces scannability.

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 creation tool with no output schema and no schema descriptions, the definition supplies the placement, sizing, rotation, and segment semantics an agent needs, plus a note on the returned size/box. It is nearly complete, with only the 'kind' enum meanings and naming conventions left unstated.

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

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

With 0% schema description coverage across 7 parameters, the description carries the full burden and mostly delivers: it explains size semantics (including the torus-specific [outer width, outer depth, tube thickness]), segments as the count around the ring, anchor as bounding-box fractions 0..1, at as the world point, and rotate_deg as [rx, ry, rz] with order. Only 'kind' enum values and 'name' are left implicit, which is minor.

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: 'Create a primitive with a real size in metres (no hidden scale).' It clearly defines the geometric construction domain and even names the shape set indirectly through the torus example. However, it never distinguishes itself from siblings like loft, text_mesh, or build_from_grid, so it stops short of full sibling differentiation.

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

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

Usage is implied rather than stated: an agent can infer this is the entry point for placing a parametric shape at a world point. There is no explicit when-to-use or when-not-to-use guidance and no reference to alternative creation tools among the many siblings. Adequate but leaves routing 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?

Annotations already flag it as destructive (readOnlyHint false, destructiveHint true). The description adds mode-specific effects beyond annotations: collapse can distort shapes and UVs and should be validated with compare_view, while planar removes flat coplanar faces with minimal shape change. It stops short of describing what data is destroyed or any permission requirements.

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

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

The definition is front-loaded with the core purpose, then uses two compact mode-specific clauses. Every sentence earns its place and parameter names are formatted clearly with backticks.

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

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

Given no output schema and annotations covering the destructive safety profile, the description is nearly complete: it explains behavior and mode selection. The main gap is the required 'object' parameter, which is never mentioned, leaving the agent to infer it from the schema property name.

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

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

With 0% schema description coverage, the description must compensate. It explains mode, defines ratio as 0..1 of current triangles, notes target_tris as an alternative, and describes angle in degrees. It entirely omits the required 'object' parameter and does not clarify defaults or the target_tris type.

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

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

The description gives a specific verb and resource: 'Reduce the triangle count,' then defines the two operational modes. This clearly separates it from siblings like subdivide (increases geometry) and repair_mesh (fixes topology).

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 provides clear context for each mode: collapse for hitting a ratio/target_tris, planar for cleaning flat subdivided surfaces, and recommends checking with compare_view after collapse. However, it does not state when to choose decimate over alternative reduction tools or list any explicit exclusions.

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

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

Annotations declare destructiveHint=true, and the description goes well beyond that: it explains that users are moved to the first material, extras deleted, repeated in-mesh slots joined, and which cleanup flags delete what (empty/unused slots, orphans). It also flags the risky edge case that empty slots still referenced by faces are kept and listed in `faces_without_material`.

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?

Dense and front-loaded with the core merge behavior before the cleanup caveats, and nearly every sentence carries distinct information. It runs long and could compress the per-flag cleanup enumeration, but 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?

With no output schema, the description still reports what is returned (removed count, before/after material counts, empty_slots_removed, unused_slots_removed, orphans_removed, faces_without_material) and covers the destructive semantics that the annotations only hint at. Nothing needed to invoke it safely 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 0%, so the description must carry the full burden, and it does: `names` limits the check, `tolerance` is explained with units and the 0.01 = 1 percent example plus the tolerance=0 special case, and clean_slots/remove_orphans are each tied to their effect and returned counters.

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

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

States a specific verb and resource ('merge materials that look the same') plus the exact matching criteria (colour, roughness, metallic, alpha, emission, coat, textures). An agent can distinguish this from set_material, list_materials, and procedural_material without opening any schema.

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

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

Gives clear operative conditions: `names` limits the check, `tolerance=0` merges only exact copies, and textured/procedural materials merge only when images and node types match. It never names an alternative tool or states when NOT to dedupe, so it falls short of full routing guidance.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond annotations: the vertex-density requirement and that subdivide_faces should precede it, plus that origin defaults to the object origin.

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

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

Front-loads the purpose, then walks through parameters in a compact, information-dense way. Every sentence targets a parameter or prerequisite; slightly dense but 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 exists, and for a destructive mutation tool the description supplies purpose, units, geometry semantics, and a prerequisite. The main gap is the undocumented lock_x/lock_y flags, which an agent may need to interpret.

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 coverage the description carries the burden, and it delivers: it specifies amount units (degrees for bend/twist, factor for taper/stretch), the axis meaning per kind with a worked example, origin as a world point, and limits as a [0,1] fraction. It leaves lock_x, lock_y, object, and kind unexplained, so it covers roughly half the parameters richly.

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 (bend/twist/taper/stretch) and resource (the whole mesh), enumerating the exact deformation modes. It is clearly distinguishable from siblings like transform_objects, sculpt, or noise_displace without opening any schema.

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

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

Gives a concrete prerequisite: 'The mesh needs enough vertices along the axis: subdivide_faces first,' routing the agent to subdivide_faces when appropriate. It lacks explicit when-not conditions or alternative-tool exclusions, but the prerequisite guidance is clear context.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavior: with_children=true cascades to parented objects, otherwise children are unparented and returned in the answer as `unparented`, plus the checkpoint recommendation. It does not mention irreversibility beyond the checkpoint hint, so not a full 5.

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

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

Front-loaded with the core action, then selectors, then child behavior, then the alternative. Dense but every clause carries information. Slightly sprawling with parentheticals, keeping it short of a 5.

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, but the description partially covers returns (children reported as `unparented`). Selector requirements, cascade behavior, and the sibling alternative are all present, leaving only return-format details thin for a destructive, multi-mode tool.

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

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

Schema description coverage is 0%, so the description must carry all four parameters — and it does: `names`, `prefix` with a concrete example ('bl_light_' removes setup_lighting), `lights` with both enum values explained (added = lights made by add_light, all = every light), and `with_children` semantics. This fully compensates for 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?

States a specific verb+resource ('Delete whole objects') and explicitly distinguishes the scope from the sibling delete_faces ('Use delete_faces to remove a part of a mesh'). An agent can tell which deletion tool to pick without opening either schema.

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

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

Names the alternative tool and the condition that selects it (partial mesh deletion -> delete_faces), and gives a prerequisite/when-to-use caution ('Take a checkpoint first if you are not sure'). It also states the selector requirement (at least one of names/prefix/lights), which is real routing guidance.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real context beyond that: what the operation produces (openings), how the selector behaves ({} or null picks everything), and the default angle of 25 degrees. It does not cover reversibility or failure modes, so not 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?

Front-loaded with purpose and the sibling distinction, then the selector grammar. Dense but every clause is load-bearing for a 0%-coverage schema. Slightly long for a single paragraph, which keeps it off a 5.

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

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

Given no output schema and only two params, the description supplies what an agent needs: destructiveness, the prerequisite inspection step, and complete selector syntax. Minor gaps remain around whether the deletion is undoable and what is returned on success.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does: it enumerates every `where` key (normal with angle default, x/y/z ranges with null-as-open, box, area, index), states the AND semantics of 'all given keys must hold', and defines the empty-selector case. Only `object` is left implicit, which is trivially inferable as the mesh name.

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 faces of one mesh) and immediately clarifies the effect ('makes openings: doors, windows, open boxes'). It also distinguishes itself from the sibling `delete` by scope (faces vs whole objects), so an agent can route correctly without opening either schema.

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

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

Explicitly routes the agent to the alternative: 'Use delete to remove whole objects.' It also gives a prerequisite ('Look at mesh_info first to see where the faces are'). No explicit when-not-to-use beyond the sibling comparison, so short of the top band.

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

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

Annotations already establish that this is a safe, non-destructive, closed-world read. The description goes further by disclosing the tolerance-based change-detection rule, that topology and material_slots are attached only when they differ, and the useful edge case that size-preserving edits still surface. It doesn't cover pagination or volume limits, which keeps 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?

The change-detection result is front-loaded, then the optional topology/material_slots detail, then usage. Dense but every sentence carries information; only the parenthetical before -> now phrasing is slightly repetitive.

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 specifies what the return contains, including the conditional topology and material_slots fields. The main gap is the unexplained `name` parameter, but for a read-only diff tool the definition is otherwise sufficient to call it correctly.

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

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

Schema description coverage is 0%, so the description carries the burden. It explains `tolerance` well (change threshold in metres, applied to movement and size), but `name` — the checkpoint reference with default 'last' — is never explained, leaving half the parameters to inference.

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

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

The description names a specific operation and resource — a diff of the scene since a checkpoint — and enumerates exactly what appears in the result (added, removed, moved/resized objects with before-and-now sizes). It is immediately distinguishable from siblings like checkpoint, rollback, and scene_tree.

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 gives concrete usage contexts: 'review a long session' or 'see what a tool did'. That is clear when-to-use guidance, but it offers no exclusions or explicit routing against the closest siblings (checkpoint, rollback, scene_tree), so it stops short of a 5.

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

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

Annotations already declare it a non-read-only, non-destructive write. The description adds real behavioral context beyond that: `linked=true` shares mesh data, rotation order is world X then Y then Z, and the default pivot is the copy's bounding-box centre *after* the offset. That ordering subtlety is exactly the kind of detail an agent could not infer 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?

Three dense sentences, front-loaded with the core action and then progressively adding linked-copy, rotation-order, and pivot-default semantics. No filler, though the pivot sentence could be tightened.

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

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

For a 6-param mutation tool with no output schema, the description covers the non-obvious transform behavior well. It omits what the tool returns (e.g. the new object's identifier) and the meaning of `name` vs `new_name`, which an agent calling this would plausibly want.

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

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

Schema coverage is 0%, so the description must carry the burden, and it does for 4 of 6 params: `offset` (metres), `linked` (mesh sharing), `rotate_deg` (axis order), and `pivot` (world point, default bbox centre after offset). `name` and `new_name` are not explained, leaving the source-identification and copy-naming semantics to inference.

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

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

States a specific verb (copy/duplicate) and resource (an object), plus the two transformations applied to the copy. It does not explicitly differentiate itself from siblings like `array` or `mirror`, which also produce derived copies, so sibling routing is left to inference.

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

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

No when-to-use guidance or named alternatives. Among ~90 siblings that also generate copies (`array`, `mirror`, `radial_array`, `scatter`), the description never says when to pick `duplicate` instead. Usage is implied by the parameter semantics only.

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

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

Goes beyond the annotations by disclosing that the scene is restored after export, that the export scale is baked into top-object node scale, that images on disk are untouched, and that unknown options surface as ignored_options. It stops short of stating overwrite/auth semantics for the target path, but the non-destructive behavior is clearly confirmed against 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?

Front-loads the core action and then attaches caveats to the parameters that need them; most sentences earn their place with concrete detail (25 MB for nine 2048 px maps). It is dense and occasionally run-on, but not 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?

For a 10-parameter mutating export with no output schema, it covers the destructive/restorative behavior, the key option semantics, and even describes the returned 'textures' payload. The remaining gap is the undocumented boolean flags (skins, tangents, animations, apply_modifiers).

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 coverage the description must carry the load and it does for the tricky parameters: draco (needs runtime decoder), influences (bones per vertex the engine reads), scale (with a concrete 0.1 m x 10 = 1 m example), and max_texture_size (with size/bytes guidance). skins, tangents, animations and apply_modifiers are left unexplained, so coverage is good but not complete.

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 ('Write a GLB') and immediately scopes it ('of the named objects (with children), or of all visible geometry'), which separates it from import_glb, inspect_glb, check_game_ready and save_blend. An agent knows exactly what artifact this produces and from which 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?

Usage context is only implied via the game-engine framing (Draco decoder, influences read by the engine, game-ready file sizes); there is no explicit statement of when to prefer export_glb over save_blend or run_spec. The reader must infer the alternatives.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutating nature is covered. The description adds real behavioral context beyond that: negative distance 'digs in', 'as one region' implies face merging, and it names the target-prerequisite tool (mesh_info). It omits what happens to the original faces or selection afterward, keeping it out of 5 territory.

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 action, then parameter semantics, then typical uses and the mesh_info hint. Every sentence earns its place given 0% schema coverage, though the dense run-on parameter block borders on terse rather than cleanly structured.

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 and 6 parameters, the description documents all behavioral knobs, workflow order, and the where-filter grammar, while annotations cover the safety profile. It only lacks detail on the post-extrusion state (return value, face identity), which is minor for this class of tool.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so thoroughly: distance (average normal, negative direction), offset (world vector alternative), scale (taper about centre), inset (metres), and an exhaustive spec of the `where` sub-keys (normal/angle, x/y/z ranges, box, area, index, {} meaning everything). This compensates completely for the missing schema docs.

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 ('Extrude the picked faces as one region') and quantifies the scope ('as one region'). An agent can distinguish this from siblings like inset_faces, extrude_profile, or transform_region without opening any schema.

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

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

Gives concrete usage context ('raise a roof, make a post, a step, a window recess') and a workflow prerequisite ('Look at mesh_info first to see where the faces are'). It stops short of naming alternatives or exclusions, so it does not reach the routing precision of a 5.

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

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

Annotations already declare a non-read-only, non-destructive, closed-world operation, but the description adds genuinely new behavior: the solid is centred on its depth, holes are cut with boolean checks, and a flawed cut is kept rather than aborting the operation and is surfaced in `warnings`. That failure-handling contract is exactly the kind of trait annotations cannot express.

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 dense but non-redundant detail on plane conventions, offset, holes and use cases. Every clause carries information; it is slightly long but nothing reads as filler.

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

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

For a non-destructive creation tool with no output schema, the description supplies what is missing: geometry conventions, offset semantics, hole behavior and the fact that problems are reported in `warnings` rather than raised. An agent has enough to invoke it correctly on the first attempt.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so: it defines the coordinate ordering of `points` for each `plane` enum value and the resulting axis of `depth`, explains that `at` shifts the result in world space, and specifies `holes` as same-coordinate polygons or trace_outline's `holes`. Only `name` goes unexplained, which is trivial.

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

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

States a specific verb+resource with scope: 'Make a solid by extruding a closed 2D polygon'. The mention of a closed 2D outline cleanly separates it from face-based sibling extrude_faces and from lathe/sweep/loft, so an agent can route without opening a schema.

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

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

Gives concrete when-to-use context ('soles, panels, signs, floor plans, outline-based parts') and links to trace_outline as the source of `holes`. It does not, however, name an alternative for when an existing mesh face should be extruded instead (extrude_faces), so no explicit exclusions are given.

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

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

With annotations already covering the read-only, non-destructive safety profile, the description adds rich behavioral detail: grouping logic, how the main group is chosen, tiny-gap detection, default touch/search/near values, max_listed folding, and even the nearest-part output. This is well beyond what the annotations provide.

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 is front-loaded and most sentences carry necessary information, especially the default-value rules that compensate for missing schema descriptions. The text is dense and could be more scannable, but it avoids empty filler.

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

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

For a complex spatial analysis tool with no output schema and no parameter descriptions, the description covers purpose, behavior, defaults, usage, and output shape well. The main omission is the names parameter, which prevents a perfect score.

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 successfully defines ground_z, touch, near, search, and max_listed defaults and units, but the names parameter is never explained, leaving one of six parameters semantically undocumented.

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

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

The description uses a specific verb and resource: 'Find parts that hang in the air.' It immediately clarifies the exact output (floating groups, nearest part, gap) and distinguishes the diagnostic operation from sibling fixers like move_to_contact and attach.

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 gives clear timing ('Run it after assembling a model') and names the follow-up tools (move_to_contact or attach). However, it does not state when not to use this tool or discuss alternative analysis tools such as check_contacts.

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

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

Goes well beyond the annotations: it discloses that a checkpoint 'before_fit' is taken first and that rollback undoes it, that the guard refuses moves which raise IoU but hide a part (with the max_hide semantics and 1 = off), what the answer contains (rejected moves and visible_share [before, after]), and the background-job behavior (after `wait`, the answer becomes a job id for job_status). These are exactly the operational traits an agent needs and none are derivable from readOnlyHint/destructiveHint.

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

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

Long but appropriately sized for an 18-parameter tool, and it is front-loaded: purpose and the when-to-use condition come first, then inputs, then the guard and checkpoint/job behavior. Some sentences are grammatically tangled ('Move, scale and tilt parts by itself') and a few (e.g. the scale-per-view example) could be tightened, but there is little true filler.

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

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

For a complex mutation tool with 18 params and no output schema, it covers the essentials an agent would otherwise guess wrong about: the checkpoint/rollback contract, the hide guard and its return fields, and the deferred job-status flow. The remaining gap is the unexplained tuning parameters, which prevents a 5.

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 coverage the description carries the full burden, and it does explain the hardest parameters: the per-view `references` mapping, `names` semantics ('everything visible but a huge floor or backdrop when empty'), the single-number-or-dict per-view form of height_m/width_m and the view-name-wins rule, `mirror_pairs`, `tune`, and `max_hide`. However, many numeric knobs that materially change behavior (size, step_m, scale_step, threshold, iterations, max_shift, max_tilt, tilt_deg, time_limit) are entirely unexplained, so the coverage 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 set (move, scale, tilt), the resource (parts), and the mechanism/goal (raise match with reference silhouettes via world-registered IoU). It implicitly separates itself from sibling measurement tools ('as compare_view measures it') and from pure transforms (transform_objects/apply_transforms), so an agent can distinguish it without opening schemas.

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

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

Gives a clear selection condition and an exclusion: 'Use it when the forms are roughly right: it fixes placement and proportions, not shapes.' That tells the agent both when to reach for it and when not to. It stops short of naming a specific alternative tool for the 'wrong shapes' case, so it is strong but not fully 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it will not look at any other object (so overlaps are possible), and empty names means all top-level objects are affected. It does not state return format, but no output schema exists to lean on.

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

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

Two dense sentences, front-loaded with the core action and followed by the scoping caveat and the routing alternative. Every clause earns its place with no filler.

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

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

For a 2-param mutation tool with no output schema, the description covers the action, both parameters, default scope, and the sibling alternative, while annotations carry the destructive profile. Slightly short of complete because it doesn't mention what happens to objects with existing transforms beyond the lowest-point alignment.

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 load, and it does: 'z' is defined as the height the lowest point sits at, and 'names' semantics (all top-level objects when empty) are spelled out. Only minor gaps remain, e.g. whether z accepts negative values or units.

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: it moves objects so their lowest point sits at a given height z, i.e. sets a level floor. It also distinguishes itself from the sibling place_on, so an agent can tell the two apart without opening either schema.

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

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

Explicitly names the alternative ('use place_on when the floor is another object or not level') and the condition that selects it. It also implies the default scope (all top-level objects when names is empty), leaving nothing to inference about when to reach for this tool.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is partly covered. The description adds useful context that new objects are created and reported with world sizes, but it omits placement/origin behavior, coordinate handling, and how path is resolved.

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 well-formed sentence with the core action front-loaded and no filler; every clause earns its place.

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

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

With no output schema, the description partially compensates by describing the return (new objects and their world sizes), and annotations carry the safety profile. For a one-parameter import tool this is nearly complete, though path semantics 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?

There is a single parameter at 0% schema description coverage, so the schema does not document 'path' at all. The description only implies it is a file path via 'GLB or glTF file', adding minimal meaning (no format, relative vs absolute, or directory semantics).

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

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

The description states a specific verb and resource ('Import a GLB or glTF file') and adds a scope note that it lists the new objects with their world sizes. This clearly distinguishes it from sibling tools like export_glb and inspect_glb, though it doesn't name those siblings 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?

Usage is implied by the verb 'import' and the file-type constraint (GLB or glTF), but there is no explicit when-to-use guidance or reference to alternatives such as inspect_glb (for inspecting without importing) or export_glb (for the reverse operation).

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

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

Annotations already declare the destructive/open-world profile, so the bar is lower. The description adds real behavioral context beyond that: default thickness (0.02 m, less on objects under 0.3 m), the meaning of negative depth (a recess), and the per-face semantics of individual=true. It does not explain reversibility or result format, but it earns credit for the defaults and recess semantics.

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

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

The core operation (thickness/depth/individual) is front-loaded, and the longer `where` clause is dense but justified given the zero schema coverage. Slightly run-on, but essentially 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 destructive mesh-edit tool with annotations covering safety, no output schema needed, and an undocumented schema, the description supplies the operation, its defaults, and a full `where` grammar. An agent has everything required 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 coverage is 0%, so the description carries the full burden and does so well: it documents `thickness` defaults, `depth` sign convention, `individual`, and exhaustively the `where` filter keys (normal with angle default 25, x/y/z ranges with null-open, box, area, index, and {} / null meaning everything). This is strong compensation for 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 opens with a precise verb+resource ('Inset the picked faces') and immediately specifies the operative parameters (`thickness`, `depth`, `individual`). This is clearly distinct from siblings like extrude_faces or bevel_edges — an agent can tell it apart 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 gives a useful prerequisite hint ('Look at mesh_info first to see where the faces are'), which is a genuine workflow cue. However, it never states when to choose this over alternatives such as extrude_faces or bevel_edges, nor any when-not conditions, 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 readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it runs standalone without a Blender session and it enumerates the specific warnings it surfaces (missing normals/UV, oversized or non-power-of-two textures, duplicate node names), which tells the agent what failure modes it will detect.

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

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

Two sentences, zero waste. The capability list is front-loaded and the usage rationale follows immediately, so an agent gets both what and when in a single glance.

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 read-only inspection tool with no output schema, the description enumerates the reported fields thoroughly and annotations carry the safety profile. The only real gap is the undocumented max_texture threshold, which leaves one invocation decision unresolved.

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

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

Schema description coverage is 0% and neither parameter is explained. 'path' is inferable from context, but 'max_texture' (default 2048) is never mentioned, even though the description alludes to 'oversized' texture warnings — the parameter that presumably sets that threshold is left undefined, so the description does not compensate for the coverage gap.

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

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

States a specific verb (read) and resource (a GLB file), then enumerates exactly what it reports: triangles, vertices, materials, textures with sizes, extensions, file size, and warnings. The phrase 'without Blender' distinguishes it from in-scene siblings like check_mesh, mesh_info, and import_glb, which operate inside the Blender session.

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?

'Run it on the file you exported, because that is what the game loads' gives clear context for when to reach for this tool — validating the exported artifact. It stops short of naming alternatives (e.g., check_mesh for in-scene geometry) or stating when not to use it, so it is clear guidance without explicit 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?

Goes well beyond the annotations (readOnly=false, destructive=false): it explains that cancel=true stops the job, that already-applied scene changes PERSIST, and that rollback is required to undo them. That is exactly the 'what survives/what gets destroyed' context the annotations cannot express, and it is consistent with 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?

Three sentences, front-loaded with the resource and its states, then the trigger condition, then the mutation/undo semantics. Every clause (including the named long-running tools) 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 supplies the return-value shape (progress/result/error) itself, covers both parameters despite 0% schema coverage, and reconciles the mutation with the destructive=false annotation. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry both parameters — and it does: omitting `job` lists all jobs, and `cancel=true` stops the job. It does not state the expected format of the `job` id, a minor residual gap.

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

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

States a specific resource (background job) and enumerates the returned states (running/done/failed), so the agent knows exactly what this reports. It never explicitly distinguishes itself from the sibling `status`, which is the only real ambiguity in an otherwise clear statement.

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

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

Gives the precise trigger condition (long tools like fit_to_reference/match_camera/bake_maps return a job id when they exceed `wait`), the no-argument behavior (lists all jobs), and routes the undo case to the `rollback` sibling. Nothing about when to reach for this tool 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 annotations already declaring this a non-destructive write (readOnlyHint=false, destructiveHint=false), the description usefully adds outcome behavior: close=true closes the loop into a ring, angle under 360 yields a wedge. It does not mention where the new object lands in the scene, whether it is undoable, or how it interacts with existing geometry, so it stops short of full transparency.

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

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

The core action is front-loaded in the first sentence and the remaining sentences each add distinct shape/topology information without filler. It is dense but every clause earns its place; it could be tightened slightly but wastes little.

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, but the description compensates by enumerating the resulting geometry types. For an 8-parameter geometry-creation tool it is reasonably complete on the central concept, though it omits what `name`, `at`, `axis`, `cap`, and `segments` control and does not say it creates a new scene object.

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, and it does define `profile` (list of [radius, height] points bottom-up), `close`, and `angle`. It leaves name, at, axis, cap, and segments entirely unexplained, so over half the parameters remain opaque.

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

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

"Spin a profile around an axis" gives a specific verb (spin/lathe) and resource (profile) and even enumerates the resulting shapes (vase, bottle, donut, wedge). It is clear what the tool produces, but it never contrasts itself with close siblings such as sweep, extrude_profile, or radial_array, so an agent gets no explicit disambiguation.

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 how profile topology maps to output (axis-touching = solid, off-axis = tube, angle < 360 = wedge), which implicitly guides usage. However, it never states when to choose lathe over sweep/extrude_profile/loft, nor any prerequisites or when-not-to-use conditions, 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 already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful geometry behavior ('ends are rounded and stay inside the path'), but says nothing about whether it creates a new object, needs a selection, or how apply=true affects the scene.

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

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

Three tight sentences, front-loaded with the core action and output before the radius rule and use cases. No filler, though the 'Good for arms, legs...' list is more flavor than essential 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 six-parameter creation tool with no output schema and no parameter documentation, the description conveys the result geometry and radii rule but omits return values, object naming, and the effect of sides/subdivisions/apply. Adequate but with clear gaps an agent would hit in practice.

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

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

Schema description coverage is 0%, so the description carries the full burden and only partially meets it. It clarifies radii semantics well ('one radius per point, or one radius for all'), but points, name, sides, subdivisions, and apply are left entirely 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 concrete verb and output ('Make a smooth tube along a polyline of world points') plus the technique used ('Skin plus Subdivision'), so an agent knows exactly what geometry it produces. It stops short of naming sibling generators (sweep, loft, extrude_profile) that also build geometry along a path, so differentiation is only partial.

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 'Good for arms, legs, tails, tentacles, branches' gives real use-case context for when this tool fits. However it offers no when-not guidance and never points to alternatives such as sweep, loft, or extrude_profile, leaving the agent to infer which path-based generator 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?

The annotations already establish this as a safe, non-destructive read. The description adds important behavior beyond the annotations: object names resolve to bounding-box centres, the two named objects never block the ray, and the result is the first blocker.

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

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

The description is front-loaded with the core question, then efficiently adds parameter semantics, ray-blocking behavior, return value, and intended use. Every sentence adds value without repetition.

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

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

For a two-parameter visibility query with no output schema, the description supplies the essential input forms, blocking rule, return value, and typical use cases. An agent has enough information to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does so fully by explaining that each parameter may be a world point or an object name, and that object names use the bounding-box centre.

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 query: whether point or object `a` can see `b`. It clearly describes the resource and operation, but does not explicitly differentiate itself from nearby siblings such as `sightline_map`, `viewshed`, or `raycast`.

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 gives a clear use context: 'Use it for sight lines, cover and corridors.' However, it does not state when not to use it or which alternative siblings are preferred for related visibility tasks.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the shape of the return values (parent, world head/tail, length) and says nothing about errors, armature lookup behavior, or whether bones are filtered. Minimal added context 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 short sentence with no padding, which is efficient. But it is a sentence fragment that front-loads the return fields rather than the action, so it is terse rather than well-structured.

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 one-parameter read tool with no output schema, the description usefully enumerates the returned fields, partially compensating for the missing output schema. However, the required armature parameter remains unexplained, which is a real gap for invocation correctness.

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

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

Schema description coverage is 0%, so the description carries the full burden for the single 'armature' parameter, yet it never explains how the armature is identified (name, object reference, path). The phrase 'of an armature' only weakly implies the parameter selects the armature, which is insufficient compensation for the coverage gap.

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

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

The description names the resource (bones of an armature) and enumerates the returned fields, which lets an agent infer this is a listing/read tool. However, it never states the action verb explicitly and doesn't distinguish itself from armature-related siblings like create_armature or bind. Purpose is inferable but vague.

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 such as create_armature, bind, or pose. There is no mention of prerequisites or context of use; the agent must infer usage from the name alone.

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

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

Annotations already declare readOnly/non-destructive/not-open-world, so the safety profile is covered. The description adds genuine behavior beyond that: it defines the `preset` flag's meaning (true for bl_light_* lights created by setup_lighting) and points to delete for mutation, which is useful context.

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

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

Two compact sentences with the core action front-loaded and no filler. The trailing deletion note is slightly tangential to the tool's own function, but it is brief and useful for routing.

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

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

There is no output schema, so the description carries the burden of explaining what is returned, and it does so thoroughly (name, kind, place, direction, power, colour, settings, preset). For a parameterless read tool this is 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?

There are zero parameters, so per the rubric the baseline is 4. The description introduces no parameter information (none exists), and the schema fully covers the empty object, so no compensation 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 opens with a specific verb and resource ('List every light in the scene') and enumerates the returned fields, so the agent immediately knows what it returns. It references related siblings (setup_lighting produces the bl_light_* lights; delete removes lights), which helps distinguish it, though it doesn't explicitly contrast with other list_* 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?

Usage is implied rather than stated: it's a scene-inventory listing, and the last clause routes to delete for removal. There is no explicit 'use this when...' or condition distinguishing it from siblings like scene_tree or list_materials, so guidance is only implicit.

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

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

Annotations already declare readOnly/non-destructive, but the description adds substantial behavioral context beyond them: procedural nodes are not exported to glTF and are marked `not_exported`, `faces_without_material` counts empty slots per object, and it explains `alpha_mode` vs `render_method` and the normal map colour space requirement. No contradiction with 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?

The definition is dense and mostly front-loaded: the first sentence states the default output, then the `name` behavior follows. Every sentence adds value, but the description is long and somewhat sprawling, with multiple clauses that could be organized more tightly. It is efficient but not maximally concise.

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

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

Given the annotations cover safety and no output schema exists, the description fully explains return values, field meanings, and special cases like glTF export behavior and `render_method`. Nothing an agent needs in order to call and interpret this read-only inspection tool 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 0% for the single optional `name` parameter, so the description must carry the full burden. It does: 'With `name` the answer is the card of that one material' and then details exactly which fields that card contains, making the parameter's effect and output shape unambiguous.

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 (list/inspect) and resource (materials), and distinguishes between the all-materials list and the single-material card via the `name` parameter. It also names sibling tools (`dedupe_materials`, `assign_material_faces`) to contrast its role. An agent can tell exactly what this tool returns and how it differs from nearby 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 gives explicit usage context: 'Use it to find look-alikes before dedupe_materials' and points to `assign_material_faces` for fixing empty slots. This is clear when-to-use guidance tied to sibling tools. It does not state explicit when-not-to-use conditions, so it falls short of a full 5.

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

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

Annotations already declare this is a non-read-only, non-destructive, closed-world creation tool, so the safety profile is covered. The description usefully adds that the output is a 'closed body', that sections must be ordered along the axis, and what 'roundness' values mean, but it never states what is returned (new object name/handle) or any post-creation behavior. With annotations carrying the safety burden, this is adequate but not rich.

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

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

Front-loaded with the core action and the section format, then routing guidance. Dense but every sentence adds information; only the inline JSON example makes it slightly heavy to parse.

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 creation tool with annotations covering safety and no output schema, the description covers the non-obvious parts: section data shape, ordering, and the loft_from_masks alternative. The remaining gap is unexplained geometry controls (axis, segments, subdivisions) and no indication of the return 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 description coverage is 0% and the 'sections' items object is opaque (additionalProperties: true), so the description carries the full burden — and it does document the critical nested shape with a concrete example ({'at': [x,y,z], 'size': [w,d], 'roundness': 2}) plus the roundness scale (2=ellipse, 4=rounded box) and ordering rule. It leaves axis, caps, segments, and subdivisions unexplained, which prevents a 5.

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: 'Make a closed body from cross-sections you give as numbers along an axis.' It also names the sibling it is not (loft_from_masks) and the shapes it targets, so an agent can distinguish it from array, lathe, sweep, and extrude_profile without opening schemas.

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

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

Gives concrete when-to-use examples ('torsos, heads, bottles, columns') and an explicit alternative with a selecting condition: 'With a front and a side image of the form use loft_from_masks.' That is an explicit when/when-not plus 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?

Annotations only declare the safety profile (not readOnly, not destructive, closed world), so the description carries the real burden and delivers: it explains how cross-sections are derived from both images, the full-height span, and that the first and last band end flat. It still omits whether an object is created fresh vs. replaced and what happens on failure.

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

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

Information density is high and the purpose is front-loaded, but it is delivered as one unstructured run-on paragraph with no separation between core behavior and per-parameter notes. Clauses largely earn their place, yet a bulleted or sentence-split form would scan far better.

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

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

For a 13-parameter geometry tool with no output schema and no annotation depth, the description covers the conceptually important knobs but leaves more than half the parameters (including the required height_m) undocumented. It is usable but not fully sufficient to invoke correctly without guessing.

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

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

Schema description coverage is 0% across 13 parameters, so the description is the only source of meaning. It usefully defines part, side_faces, z_range, and roundness, but leaves at, name, bands, segments, threshold, subdivisions, and the required height_m completely unexplained.

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

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

The opening states a specific verb and resource ('Build one rounded body from a front and a side silhouette image') and explicitly routes numeric-input cases to the sibling 'loft', so an agent can separate the two. The remaining text is mostly mechanics, but the core purpose is unmistakable.

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 names the alternative ('with numbers instead of images use loft') and gives selection criteria between the two enum modes ('part=largest uses the widest run... part=extent uses everything'). It stops short of stating prerequisites, e.g. that a 3D scene/object must exist or what happens if the silhouettes don't align.

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

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

Goes well beyond the annotations: discloses that the camera is created/updated and becomes the scene camera (a side effect), the fallback starting strategies, the background-job mode returning a job id for job_status after `wait` seconds, and the exact return fields (location, rotation, look_at, fov_deg, IoU before/after). This is rich behavioral context consistent with readOnlyHint=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?

Dense and front-loaded, with the core purpose and alternative stated first. Most sentences earn their place, though the parameter-detail block is long and could be tightened slightly.

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

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

For an 11-param mutation tool with no output schema, it covers the essential behavior, starting conditions, return values, and background-job path. The gaps are minor (undocumented `names` and `time_limit`).

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 coverage across 11 parameters, the description compensates well: it explains init with an example, fov_deg semantics (angle fixed on the longer image side, distance/FOV tradeoff), ground_z, size, iterations, threshold, camera, reference, and wait. Only `names` and `time_limit` are left undocumented.

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

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

States a specific verb+resource ('Find the camera that shows the model like a perspective photo') and immediately distinguishes itself from the sibling compare_view for flat orthographic views. An agent can identify the tool and its scope 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?

Names the alternative compare_view and the condition selecting it, and points to overlay_reference for the front/back ambiguity on symmetric models. It also gives start-condition guidance, but does not state explicit when-not-to-use boundaries beyond the orthographic 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuine behavioral detail beyond the annotations – that output Notes may report 'scale not applied' or 'negative scale' – but does not cover invalid names, empty arrays, or cost. Useful incremental context against a low bar.

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

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

Dense but efficient: the return fields are front-loaded, followed by usage and the alternative. Every clause carries information and there is no filler, though the opening field list reads as a run-on.

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 does the right thing by enumerating the returned fields, which largely covers the return contract. However, it says nothing about the required 'names' input, and for a tool an agent is told to call after every move, that input contract should be stated.

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

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

Schema description coverage is 0% and the single parameter 'names' is a bare array of strings with no description. The description never explains what 'names' refers to (object names? scene paths?), so it fails to compensate for the coverage gap; only the phrase 'after every move' hints at the input.

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

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

The description enumerates the exact quantities returned (world-space size, min/max, center, origin position and its normalized coordinates, rotation, scale), so an agent can tell this is a per-object measurement query. The verb is implied by the name 'measure' rather than stated, but the scope is unambiguous and it distinguishes itself from measure_profile 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?

It gives a concrete trigger ('Use it after every move') and names the alternative for a common adjacent case ('Use measure_profile to measure a reference image instead of an object'). No explicit when-not beyond that one alternative, but the routing condition 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 a safe read-only, non-destructive profile, yet the description goes well beyond them: it discloses the exact return structure per band (width, left/right edge from centre, separate runs for arms/legs, filled width), the coordinate frames for the grid (x from silhouette box centre, z from its bottom, labels in millimetres), and where the outline comes from ('alpha or from the corner colour'). This is unusually rich context for a measurement 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?

Purpose and the measure/measure_profile distinction are front-loaded, and the following sentences each add a distinct piece of information (return shape, outline source, grid/region/out behavior). It is dense rather than padded, though the return-shape enumeration makes it longer than strictly necessary.

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

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

For an 8-parameter tool with no output schema and zero schema descriptions, the description supplies the return format, coordinate conventions, image-source dependency and file output, so an agent can call it correctly. The two unexplained parameters (bands, threshold) are the only meaningful omission.

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

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

Schema description coverage is 0% across 8 parameters, so the description must carry the load, and it explains most of them: height_m ('image height is mapped to height_m'), grid, region ([x0, z0, x1, z1] in metres), grid_size (long side in pixels) and out (saves it to a file). It leaves 'bands' and 'threshold' undocumented, which is the main remaining gap.

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

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

States a specific verb and resource ('Measure a silhouette in a reference image in metres') and immediately disambiguates from the nearest sibling: 'use measure for an object of the scene.' An agent can choose between measure_profile and measure without opening either schema.

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

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

Gives clear routing ('use measure for an object of the scene') plus concrete downstream uses for the numbers: 'loft sections, assert_spec checks or to find where the model differs.' It does not state prerequisites (e.g. that the reference must have alpha or a distinguishable corner colour) as an explicit when-not, so it stops short of a 5.

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