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

With no annotations, the description carries the full behavioral burden and does so richly: it explains create-vs-update semantics ('same name updates that light; it never makes a copy'), default placement for omitted location/look_at, preservation of omitted fields on update, power/color/temperature semantics, shape-specific constraints, and name restrictions. This is comprehensive 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?

It is a dense but front-loaded paragraph; the first sentence states purpose and the main alternative, then each subsequent sentence explains a distinct parameter group. The length is justified by 13 parameters, though bullet formatting could improve scanability.

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

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

For a 13-parameter mutation tool with no annotations and no output schema, the description covers what an agent needs: creation/update behavior, defaults, constraints, naming rules, and practical guidance. Return values are not described, but none are provided in an output schema, so completeness is high.

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: it defines kind, location (world metres), look_at aim point, power_w units and practical wattages, color formats, temperature_k range/effect, spot_size_deg range, blend range, cutoff_m, radius source size, size area dimensions, and shadow_soft. Nearly every parameter receives meaningful semantics beyond its 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 starts with a specific verb+resource ('Create or update one light') and immediately distinguishes it from the sibling setup_lighting ('makes a whole preset instead'), so an agent can select it without opening other 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 explicitly names when to use an alternative ('setup_lighting makes a whole preset instead') and when not to use it ('Names that start with bl_light_ belong to setup_lighting and are refused'), plus points to delete for removal. This gives clear 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?

With no annotations the description carries the full burden, and it does disclose real side effects: shared meshes are made single-user first, children keep their world position, and mirrored scale is handled without flipped normals. This is genuine behavioral context beyond the schema. It stops short of stating undo/permission implications or whether the operation is destructive to linked data.

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 the non-obvious side effects. Dense and jargon-appropriate for a DCC tool; nothing is wasted, though the mode explanation could be slightly more 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?

No output schema and no annotations, so the description must stand alone — and it covers the mutation's non-obvious effects well. It is still thin on the `names` argument and on whether the change is reversible, which for a transform-baking mutation is a meaningful gap.

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

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

Schema coverage is 0%, so the description must compensate. It explains the `all` mode semantics (origin moves to world origin) and implies the scale/scale_rotation distinction, but the `names` parameter is never explained — the reader must infer it is the list of target meshes.

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 — 'Bake the transform of meshes into their vertices' — and anchors it to a familiar operation ('as Ctrl+A does'). An agent can distinguish this from sibling transform_objects, which moves objects rather than collapsing their transforms into geometry.

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 Ctrl+A analogy gives a usable mental model, and the description clarifies what mode `all` does beyond the default. However, it never states when to choose this over transform_objects or set_origin, nor any prerequisite such as needing existing objects or a selection.

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

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

With no annotations, the description carries the full burden. It usefully discloses the key behavioral trait that copies are merged into a single mesh, but it says nothing about whether the source object is consumed or preserved (the keep_source parameter defaults to false), nor about permissions or result format.

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, front-loaded with the operation, followed by a compact illustrative list. No filler; every clause adds 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 5-parameter mutation tool with no annotations and no output schema, the description covers the core mechanics but omits keep_source semantics and the fate of the source object, which are exactly the details an agent needs before invoking.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate. It clarifies count (repetition number) and offset (world vector, step in metres), which is genuinely useful, but leaves object, name, and especially keep_source completely undefined.

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

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

States a specific verb+resource: repeat an object count times along a world vector and merge copies into one mesh. The 'world vector offset' phrasing implicitly distinguishes it from the sibling radial_array (linear vs radial repetition), so an agent can pick correctly 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?

The example list ('Fences, stairs, windows, planks, teeth') gives concrete when-to-use contexts, which is stronger than most tool descriptions. However, it offers no explicit when-not guidance or a named alternative (e.g. radial_array for circular patterns).

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

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

With no annotations, the description carries the full burden and does disclose return behavior: failures expose 'actual', 'expected' and a 'fix' tool, and bad checks or missing objects are reported as 'error' while the rest still run. It does not state read-only vs mutating semantics, but the per-check reporting detail is substantive beyond structured fields.

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

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

Dense but front-loaded: the one-call purpose and expectation-ordering advice come first, then the check catalogue. Length is justified by the mini-language it documents, though the type list could be tighter.

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 and no annotations, yet the description explains both inputs (the check DSL) and outputs (pass/fail with actual/expected/fix, or error with partial execution). An agent has enough to construct a call and interpret the result.

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

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

Schema coverage is 0% and the single 'checks' array is opaque in the schema, so the description must compensate entirely — and it does, enumerating eleven check types with their fields (size, position, ratio, gap, contact, symmetry, inside, on_ground, clean, budget, connected). This is far more than the schema provides.

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

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

The opening sentence states a specific verb and resource ('run all checks in one call, get pass or fail'), so the agent knows this is a batch assertion runner. It does not explicitly name which sibling it supersedes (run_spec, check_mesh, check_symmetry), leaving the agent to infer the distinction from the sibling list alone.

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

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

'State your expectations before you look at the result, then fix only the failures' gives workflow guidance about ordering, and 'run all checks in one call' implies batch use. However there is no explicit when-to-use versus run_spec or the individual check_* tools, and no exclusions stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses that a slot is auto-added when missing, that unselected faces keep their material, and the performance cost per material. It omits permissions/error behavior and whether the operation is reversible, 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-loads the core action before the draw-call caveat and the `where` grammar. Dense but every sentence conveys usable information; only minor tightening possible.

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 annotations and no output schema, the description covers action, side effects, prerequisites, and the filtering grammar. It stops short of describing failure modes (nonexistent material/object) or response shape.

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

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

Schema coverage is 0%, so the description must compensate. It fully documents the complex `where` parameter (normal/angle, axis ranges, box, area, index, empty/null semantics), leaving only the self-evident `object` and `material` names unexplained.

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

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

States a specific verb+resource: 'Put an existing material on the picked faces of one mesh.' It also distinguishes itself from the sibling set_material by noting the material must already exist and instructing to create it first.

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?

Explicit prerequisites and routing: create the material first with set_material, and inspect with mesh_info before picking faces. It also gives a when-to-care condition (keep material count low due to per-material draw calls).

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it explains that children move with `part`, that `with_children=false` changes only how the bounding boxes are measured, and that `offset` is in metres. It also documents the return payload (`boxes_used`, `moved_by`) and clarifies that top-level min/max refer to `part` alone.

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 move semantics, then layers in anchor details, child behavior, return values, and alternatives. Despite covering a complex operation, every sentence carries actionable information 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?

Given the tool's complexity, zero annotation coverage, no output schema, and 0% schema description coverage, the description supplies everything an agent needs: purpose, parameter semantics, side effects, return values, limitations, and sibling alternatives. Nothing material is missing 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 compensate, and it does: it defines anchors as fractions 0..1 per axis with examples, explains the default top placement, specifies that `offset` is in metres, and clarifies the nuanced behavior of `with_children`. This adds substantial meaning beyond the bare schema parameter names and defaults.

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

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

The description states a precise verb and resource: moving `part` so a point of its world bounding box lands on a point of `to`'s bounding box. It also distinguishes this tool from nearby siblings by naming `move_to_contact`, `place_on`, and `transform_objects` as alternatives for cases this tool does not handle.

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 when-not-to-use guidance: boxes do not follow round or slanted surfaces, so use `move_to_contact` to close the real gap, `place_on` to drop onto uneven ground, or `transform_objects` for a known offset. The default placement behavior is also stated, so an agent can choose the right tool without inference.

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

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: CPU Cycles baking, background job model with wait/job_status/cancel, per-map step timing, output file naming and default output directory, UV overlap handling, bevel_radius limitations, replace_material side effects, and the 'do not edit while running' warning.

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 long but appropriately sized for a 10-parameter tool with no schema descriptions and no annotations. It is front-loaded with purpose and the most important map semantics, then proceeds through parameters and job behavior without filler; every sentence adds actionable information.

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

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

Given the complexity, absent annotations, zero schema description coverage, and no output schema, the description is complete. It covers purpose, all parameters, behavior, prerequisites, output naming, job lifecycle, and interactions with sibling tools like check_mesh, export_glb, and job_status.

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, and it does: it explains maps values and defaults, size pixel guidance and power-of-two constraint, margin meaning, samples recommendations, bevel_radius units and normal-map-only behavior, uv_layer selection, out_dir default, wait behavior, replace_material effect, and object scope.

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: 'Bake the material of one mesh into PNG maps on its UV'. It also names the downstream reason (glTF carrying procedural/layered materials) and distinguishes itself from siblings like unwrap, set_material, and export_glb. An agent can tell what this tool does without opening the schema.

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

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

Gives clear context for when to use it (baking procedural/layered material into textures for glTF export) and conditions for map selection, UV requirements, and material setup. However, it does not explicitly name alternative tools or state when not to use this tool, so routing among 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?

With no annotations, the description carries the full burden and does so well: it discloses clamping behavior ('Overlapping bevels are clamped, and one tight edge limits every bevel of the call'), the exact returned fields (width, achieved_width, clamped, warning) and post-operation cleanup (merged_vertices, removed_zero_faces). This is unusually rich 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?

Front-loads purpose then parameters then behavior/return values, with no truly wasted sentence. The prose is dense and run-on (nested parentheticals, mid-sentence field lists), which slightly hurts scannability, but the length is justified by the tool's complexity.

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-param mutation tool with no annotations and no output schema, the description covers selection conditions, units, defaults, failure/clamping semantics and the returned fields. An agent has everything needed to call and interpret it.

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

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

Schema coverage is 0%, so the description must compensate, and it explains most params: `where` (x/y/z ranges and box), `width` (metres, default 0.02 m, smaller on sub-0.3 m objects), `segments` (1 = chamfer, 3 = round), `profile` (0.5 = circular) and one `width_type` value. It leaves the other four enum values (offset, depth, percent, absolute) and the `segments` default of 2 unexplained.

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

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

States a specific verb+resource ('Round or chamfer the edges') with a clear selection condition ('sharper than `angle` degrees'), which is enough to distinguish it from siblings like subdivide, inset_faces or solidify. An agent can identify the operation without opening the schema.

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

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

Gives concrete preconditions and scoping: edges must be sharper than `angle`, optionally restricted to a `where` box, and 'Only edges with two faces can be bevelled.' It does not name alternatives or state when NOT to use it (e.g. vs subdivide/inset), so it falls short of 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?

With no annotations, the description carries the full burden and does disclose two important behavioral traits: existing same-named groups are overwritten (a destructive side effect), and 'auto' silently falls back to proximity on dirty meshes. It omits prerequisites (e.g., armature must exist, mesh selection state) and any indication of failure modes.

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 method tradeoffs, then side effects and follow-ups. It is one dense paragraph rather than a single tight sentence, but every clause carries information and none is redundant with the schema.

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

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

For a 5-param mutation tool with no annotations and no output schema, the description covers the key decision points (method, overwrite risk, fallback) and the verification workflow via check_weights and pose_sheet. It does not describe what is returned or what happens on partial failure across multiple meshes.

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, and it does for the ambiguous params: it explains both enum values of method with tradeoffs, ties max_influences to the number of bones influencing each vertex, and identifies falloff as the proximity weighting power. 'meshes' and 'armature' are only implied by the opening sentence, and no value ranges or defaults are given.

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 and enumerates the concrete effects: 'Skin meshes to an armature: adds one vertex group per bone, the Armature modifier and the parent.' This clearly distinguishes it from siblings like parent, attach, and transfer_weights, which do not create per-bone vertex groups.

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 method choice: 'proximity' is 'fast, works on any mesh, good for stylised low-poly', while 'auto' uses heat-map weights and falls back to proximity for unclean meshes. It also names follow-up tools (check_weights, pose_sheet). It stops short of naming an alternative tool to use instead when binding is not the right operation.

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

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

With no annotations, the description carries the burden and does well: it discloses that `clear` deletes one side and defines which side (inner = negative axis side), and that fill=true closes the cut, i.e. the destructive semantics. It stops short of saying whether the source mesh is modified in place, whether a new object is returned, or any mesh-validity 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?

Three sentences, front-loaded with the core action and its plane definition, then parameter behavior, then usage. Every clause carries information; 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 5-param mutation tool with no annotations and no output schema, it covers purpose, parameter meaning, and use cases. The remaining gap is return/result behavior (in-place edit vs. new object) and failure modes, which an agent would still have to discover empirically.

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%, yet the description explains axis, at (a world coordinate, explicitly 'in metres'), clear (inner/outer semantics tied to axis sign), and fill (closes the cut). Only the obvious `object` is left implicit, so it 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 precise verb+resource ('Cut the mesh with a world plane') plus the exact mechanism (edge loop at a plane, like a loop cut placed in metres). This clearly separates it from siblings like boolean, subdivide, or extrude_faces, which do not add a planar loop.

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 enumerates when to reach for it: 'to slice, to add a loop for later extrusion, or to trim a part flat.' No explicit exclusion of the nearest alternative (boolean) or prerequisites, so it falls just 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the core algorithm (balls blend into one skin, one radius per point) and a practical tip about oversizing radii, but says nothing about whether this creates a new object, how threshold/resolution affect the result, or what is returned on completion.

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, zero filler, and the defining behavior is front-loaded before the use cases and the practical tip. 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 mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers the concept and radii well but leaves threshold, resolution, and post-call behavior undefined. Adequate to attempt a call, incomplete for confident parameter choices.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate. It meaningfully explains the points/radii pairing and gives actionable guidance on radius sizing, but threshold and resolution — both tuning parameters a caller must choose — are never mentioned, leaving two of five parameters undocumented anywhere.

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

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

States a specific verb and resource — 'Make one smooth organic mesh from overlapping balls (metaballs)' — and immediately names the defining behavior (balls merge into a single skin). An agent can distinguish this from sibling mesh-creation tools like create_primitive or rock 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 use cases ('Good for hands, clouds, bushes, rocks, creature bodies'), which tells the agent when this tool is appropriate. However, it names no alternatives or exclusions — e.g., when to prefer create_primitive, combine, or remesh — so routing between 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?

With no annotations, the description carries the full burden and does so thoroughly: it discloses that `b` is deleted, that `a` is mutated, the repair/open-mesh healing path, the exact failure conditions (edge counts and world box), the material-slot inheritance rule, welding and zero-area cleanup, and the solver fallback with micrometre-shifted tools. This is unusually complete 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?

It is densely packed and largely front-loaded (core semantics first, edge cases after), and nearly every sentence carries information. However, it is a long wall of text with no structural breaks, which slightly hurts quick scanning for a 7-parameter tool.

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

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

There is no output schema, but the description effectively documents return signals (repaired, merged_vertices, removed_zero_faces, doubled_vertices_left, solver, tool_shift_m) and error contents. For a complex boolean operation with no annotations and 0% schema coverage, this is sufficient for an agent to invoke and interpret 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, and it does: a/b roles, keep_tool, repair=true healing behavior, solver fallback semantics (and tool_shift_m), allow_open skipping the check and emitting a warning, and the difference operation are all explained. Only `union` and `intersect` enum values are left unstated, a minor gap given how much else is covered.

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 via a boolean operation) and immediately defines the roles of `a` (changed) and `b` (tool, deleted unless keep_tool), plus what difference does. This distinguishes it clearly from siblings like `combine`, `weld`, and `repair_mesh`, which perform different mesh operations.

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

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

Gives a concrete use-case cue ('Use it for windows, doors, holes, notches') and a prerequisite workflow (meshes should be closed with outward normals, verified via check_mesh). It does not explicitly contrast with the closest siblings such as `combine` or `weld`, so the alternative-selection guidance is implied rather than stated.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the observable side effects: which meshes and empties are created and under what naming convention. It stops short of stating whether existing objects with those names are overwritten, whether the operation is idempotent, or what the return payload looks like.

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

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

It is dense but front-loaded: the core action and coordinate convention come first, then the character legend, then derived outputs and validation workflow. Nearly every clause carries information, though the legend/kinds enumeration is packed tight enough that a heavier markdown structure would have aided 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 10-parameter generative tool with no output schema and no annotations, this description covers a great deal: input format, coordinate orientation, character semantics, legend override syntax, generated object names, and a follow-up validation path. It is only incomplete on the undocumented tuning parameters (origin, wall_height, floor_thickness) and on overwrite/return 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%, so the description must compensate, and it meaningfully documents layout (row 0 = top/+Y, column 0 = left), cell (metres, with 1 vs 0.5 guidance), legend (with a concrete JSON example and the full kind list), and ties cover_fill, door_height and cover_height to their in-layout characters. Gaps remain: origin, wall_height and floor_thickness are never explained, so it does not fully close a 10-parameter documentation deficit.

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 ('Block out a level from a text plan') and immediately defines the input format, so the agent knows exactly what this produces without consulting the schema. It also names the concrete artifacts created ({name}_floor, {name}_walls, {name}_cover, {name}_spawn_1 empties), which separates it from verification siblings like walkable_map and route.

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

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

It states the scenario ('block out a level from a text plan') and prescribes a follow-up workflow ('Then prove it with walkable_map, route, check_passages, sightline_map'), which tells the agent both when to call this and what to call next. It also gives a scaling heuristic ('use 1 for rooms, 0.5 for detail'). There is no explicit when-not-to-use guidance, keeping it 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?

With no annotations, the description carries full burden. It discloses output semantics in detail (deepest sample, median depth, share inside), which is valuable, but it does not state whether the operation is read-only, whether it modifies anything, or any performance/permission characteristics.

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

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

The description is a single well-structured paragraph that front-loads the state categories and then explains the overlap metrics with a concise illustrative example. It avoids repetition and the example earns its place by clarifying the difference between deepest and median depth.

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 absence of annotations, output schema, and parameter descriptions, the description covers what the tool returns well enough for a human. However, it is incomplete for reliable invocation because the two required inputs a and b are never defined, and no side-effect or error behavior is mentioned.

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 two required string parameters (a, b). The description says 'two meshes' but never maps these to a and b or explains expected identifier format (name, path, UUID, etc.), so it adds little beyond the schema's bare parameter names.

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 the tool returns a contact state between two meshes and enumerates the possible states (intersecting, touching, apart) plus depth metrics, which is more specific than restating the name. It does not explicitly distinguish itself from siblings like find_floating or check_mesh, but the focus on two-mesh overlap is clear.

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

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

It provides a direct use case ('Use it to find floating or sunken parts') but no when-not conditions and no named alternatives among the many sibling tools. This gives implied usage but leaves the agent to infer when another tool (e.g., find_floating) might be better.

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

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

With no annotations, the description carries the full burden and does so well: it defines exactly what counts as an error vs a warning, explains the subtle symmetric-but-broken-mesh case, and documents budget_only's cheap counting behavior, the over_budget output, and the draw_calls_if_instanced semantics. Gaps remain — it never explicitly says the check is non-mutating and says little about cost of the full check.

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

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

Front-loaded with the purpose and then organized into errors, warnings, and the budget mode, so the reader gets the key facts early. It is dense and information-rich, though parenthetical asides ('a boolean cutter without one leaves them', 'plane: the middle of its box, or 0') add clutter that a tighter phrasing could drop.

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 annotations and no output schema, the description supplies a lot: the ready/over_budget return semantics, both operating modes, and the meaning of each check category. It is nearly sufficient, with the main shortfall being incomplete coverage of a few input parameters and no explicit statement of side effects.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate. It meaningfully explains names, the max_* limits (tris, objects, materials, draw calls, texture), symmetry_axis, and budget_only. But require_uv and name_pattern are never addressed, and the max_* grouping is only implied, so it covers roughly half the parameters.

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

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

The opening 'Pre-export gate' plus the enumeration of errors and warnings makes it immediately clear this is a mesh/scene validation tool for export. The specific check categories (names, scale, materials, normals, textures, budgets) are far more concrete than a vague 'check' verb. It does not, however, explicitly differentiate itself from siblings like check_mesh or check_symmetry, which overlap in scope.

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

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

It states the primary context ('pre-export gate') and gives a clear conditional path: use budget_only=true 'at any stage' for the cheap budget question, and symmetry_axis=null skips the symmetry check. That is strong when-to-use guidance. It stops short of naming alternatives or saying when NOT to run the full check (e.g., its cost relative to 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?

No annotations exist, so the description carries the full burden, and it does well: it defines the return semantics of 'issues' (['none'] when clean) and 'uv' (including the texel_density_spread scale where 1 is even and above 4 is stretched, 'none' when no UV map). This is genuine behavioral disclosure beyond a normal read inspection, though it doesn't state whether the check mutates state or its performance cost.

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: it opens with the defect list and then handles the two output keys in sequence. No filler, though the run-on enumeration and mid-sentence backtick keys are slightly harder 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 no-annotation, no-output-schema inspection tool, the description covers the output interpretations an agent needs to act on results, which is the critical gap. The remaining gap is input meaning and when-to-use, but overall it is close to 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% and the single parameter 'name' is undocumented in both schema and description; the description explains outputs, not the input. With only one param the impact is small, so this sits at the minimum-viable baseline rather than below.

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 inspection verb and enumerates the exact mesh defects it detects (triangle/n-gon counts, open holes, loose parts, zero-area faces, doubled vertices, inward normals, unapplied scale), plus UV quality. This is far more specific than sibling diagnostics like mesh_info, and the agent can distinguish it from repair_mesh (which fixes) and check_symmetry/check_contacts (different checks).

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

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

The description implies a diagnostic/audit use case but never states when to run it versus alternatives like mesh_info, check_game_ready, or repair_mesh. No exclusions or prerequisites are given, so usage is inferred rather than explicit.

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

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

With no annotations, the description carries the behavioral burden and does so well: it explains the centre-line method, the doorway-versus-corridor length rule, measurement accuracy to about one cell, and that width includes agent_radius and errs on the small side. It also states that violations are returned with positions and a map. It does not explicitly declare read-only status or permissions, which prevents a perfect score.

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 purpose and then adds the algorithm, output, and start behavior in four dense sentences. Every sentence contributes useful information. It is slightly dense but not bloated.

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

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

Given 8 parameters, no annotations, and no output schema, the description is mostly complete: it covers the check logic, accuracy, return shape, and multi-level start behavior. It leaves some parameter semantics incomplete, especially names and agent_height, but provides enough for an agent to select and invoke the tool sensibly.

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 for all 8 parameters. It explains door_length, min_door, min_corridor, agent_radius, and start, and implies cell via 'one cell'. However, names and agent_height are not clarified, leaving meaningful gaps for an 8-parameter tool.

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: finding doorways and corridors that are too narrow. It distinguishes the tool from siblings like walkable_map and route by focusing on narrow-passage violations rather than mapping or routing. An agent can tell what this tool checks without opening the schema.

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

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

Usage is implied by the purpose: check a level for narrow doorways and corridors. There is no explicit when-to-use or when-not-to-use guidance versus alternatives such as walkable_map or check_game_ready. The only routing hint is a parameter note about start for multi-level areas, not tool selection.

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

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

With no annotations, the description carries the full disclosure burden. It usefully states the checkpoint is tied to the open file and invisible to other files, but omits mutation side effects, overwrite behavior for duplicate names, persistence requirements, and whether it is reversible.

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, front-loaded with the action and then the scoping caveat. No boilerplate; every sentence carries information despite slightly awkward grammar in the scoping clause.

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

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

For a simple one-parameter tool with no output schema and no annotations, the description covers purpose and scope but leaves out parameter semantics and restore/rollback context. It is not fully 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 coverage is 0% for the single 'name' parameter. The phrase 'named restore point' hints that a name is involved, but it does not explain the parameter's default ('last'), naming rules, or behavior when omitted.

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') and clarifies the object's scope ('belong to the open file'). It does not explicitly differentiate from siblings such as rollback or save_blend, so it stops short of a 5.

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

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

No when-to-use guidance; it neither names rollback as the restore counterpart nor says when to checkpoint versus save_blend/save_spec. The file-scoping note is about scope, not invocation choice.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose meaningful behavior: how `at` defaults to the bounding-box middle, how empty `tolerance` resolves to a size-dependent value (0.005 m at 0.3 m+), and that the result reports the value used. It never states whether this mutates the scene or is purely a read/measure operation, which is a notable gap for a tool whose name starts with 'Mirror'.

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 operation, then parameter semantics in three compact sentences. No filler; the tolerance parenthetical is dense but 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 does supply what the return conveys (a count of unpaired vertices plus the tolerance actually used). Combined with the default-resolution rules, an agent has enough to call it correctly; the only missing piece is confirmation that this is a non-mutating check.

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, and it does well for the two non-obvious parameters: `at` (plane position, empty = bounding-box center) and `tolerance` (auto-scaling default). `names` and the enum-constrained `axis` are self-evident and need no elaboration.

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: mirroring vertices across a plane and counting unpaired ones within a tolerance. This clearly distinguishes it from the plain `mirror` sibling, which presumably mutates geometry, though the description never names that sibling to make the contrast explicit.

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

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

The description explains mechanics but gives no guidance on when to reach for this check versus `mirror`, `check_mesh`, or other validation tools, nor any prerequisite (e.g. must objects be mirrored first, or does this tool do the mirroring itself?). Usage is only inferable from the verb.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses exactly what it checks, which is the core behavior of a diagnostic tool, and 'check' implies read-only. However, it does not state whether it modifies anything, whether it requires specific permissions, or what the return format looks like.

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

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

A single dense sentence that front-loads the category ('Skin quality') and then lists the specific issues. It is efficient, though the list-like structure is somewhat run-on and could be slightly clearer.

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 check tool with no output schema and no annotations, the description covers what is checked but does not describe the return format or how results are reported. It is adequate for an agent to understand the tool's scope but leaves gaps about the output.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions `max_influences` and explains its meaning ('glTF wants 4'), but provides no documentation for the required `mesh` parameter. The partial coverage of one of two parameters leaves a gap.

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

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

The description explicitly enumerates the specific skin-weight issues the tool detects (unweighted vertices, excess influences, non-normalized weights, orphan groups, missing Armature modifier). This is a clear verb+resource for a validation tool, though it does not explicitly differentiate itself from sibling checks 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?

No guidance is given on when to run this tool versus alternatives or prerequisites. It is implied that it is used for skinning validation, but there are no explicit when/when-not statements or references to sibling tools.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses world-space merging, material retention, and that geometry is neither welded nor moved, but it omits the destructive default that source objects are deleted (delete_sources defaults to true) and says nothing about the resulting object's name/origin or reversibility.

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

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

Three short, front-loaded sentences with no filler: the core operation comes first, then the motivation, then the boundary condition and alternative.

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

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

For a mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers the geometry semantics well but leaves the destructive source-deletion behavior and the output object's identity undocumented, which an agent needs before invoking it.

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

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

Schema description coverage is 0% and the description never names or explains any of the three parameters. It implies a plural input ('several meshes') but leaves 'name' and especially the destructive 'delete_sources' default entirely unexplained.

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

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

States a specific verb (merge) and resource (meshes into one mesh object) and anchors it to a well-known Blender operation (Join/Ctrl+J), which disambiguates it from siblings like weld, attach, and parent.

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 usage context (do it before export to save draw calls) and explicitly routes the agent to move_to_contact when the goal is closing a gap. It does not, however, say when *not* to combine (e.g. when separate objects are needed for rigging or per-part materials/animation).

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

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

With no annotations, the description carries the full burden and does so: it discloses the return payload (iou_registered, sizes, per-band table, inner_detail, hint), what happens with empty names ('everything visible but a huge floor or backdrop, listed in excluded'), flip/rotate ordering ('flip first'), and the IoU<0.3 hint behavior. This is unusually rich behavioral disclosure for an un-annotated tool.

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

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

Front-loaded with the core purpose, which is good, but the body is dense shorthand with heavy parenthetical asides and a long view-orientation block that is hard to parse. Much of the length is justified by 12 undocumented params, but the phrasing is not economical.

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

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

Given a 12-param tool with no output schema and no annotations, the description supplies return values, scale semantics, and view conventions, which is close to sufficient. Gaps remain for size/bands/threshold meaning, but an agent could 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% with 12 params, so the description must compensate, and it explains height_m, width_m, names, flip, rotate, colors, out, and view semantics (including per-view camera orientation). It leaves size, bands, threshold, and reference unexplained, so coverage is strong but incomplete.

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 ('Compare the model with a reference image in one flat view') and immediately frames it as 'the main metric of a build from references'. It also names the sibling tools (match_camera, overlay_reference) that handle the perspective-photo case, so an agent can route correctly 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 explicit when-not guidance: 'For a perspective photo use match_camera and overlay_reference.' It also explains the selection logic for height_m/width_m ('give one, and a model that is too big or too small is caught') and when the reference is auto-fitted. Clear context, though it doesn't enumerate all sibling comparisons.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses coordinate units ('world metres') and the parent-ordering constraint, but it does not describe side effects, error behavior, or whether the operation is additive to 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?

The description is front-loaded with the core action, then efficiently details bone structure and a biped example. The biped list is useful but slightly verbose; overall it is appropriately sized.

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 no annotations, no output schema, and 0% schema description coverage, the description covers input structure well. It omits return value, error handling, and explicit confirmation that it creates a new armature in the scene.

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 thoroughly documents the bone object fields (name, head, tail, parent, connect) and their constraints, though the top-level 'name' parameter is only implied by context.

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 skeleton from numbers.' It is clearly about creating an armature and not a generic mesh or primitive, but it does not explicitly contrast itself with sibling tools like limb or create_primitive.

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

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

Provides a workflow hint by naming bind and pose as follow-up tools, and gives a biped example structure. However, it does not state when to choose this tool over alternatives such as limb or create_primitive.

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

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

With no annotations, the description carries the full burden and does well: it discloses the no-hidden-scale guarantee, that size is pre-rotation, the exact rotate order (X then Y then Z about `at`, applied after placement), and that the response reports size and box post-rotation. It stops short of stating persistence/undo or naming/uniqueness behavior.

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 promise (real size, no hidden scale) and then layers geometry semantics efficiently. Dense but every clause carries information; the only minor cost is a slightly run-on middle section covering anchor and rotation 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 7-parameter creation tool with no annotations and no output schema, the description supplies the placement, sizing, and rotation model an agent needs, plus a note on what the response contains. Missing pieces are minor (naming behavior, material/side-effect details).

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 and largely does: size units and torus ordering, anchor as bounding-box fractions 0..1 with a concrete default example, rotate_deg ordering, and segments meaning for a torus. Only `name` semantics (uniqueness/collision) and the `kind` enum are left to the schema.

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

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

States a specific verb+resource ('Create a primitive') and immediately pins down the key distinguishing trait — real size in metres, no hidden scale — which separates it from import/loft/lathe siblings that also produce geometry.

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 rich semantics for how to use the tool correctly (anchor placement, rotation order, the barrel example), but never states when to prefer it over alternatives like text_mesh, import_glb, or boolean/combine workflows. Usage is implied rather than routed.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it warns that collapse can distort shapes and UVs and recommends compare_view afterwards. It also explains planar's shape-preserving behavior, though it does not explicitly state whether the operation is permanent or reversible.

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 purpose and then efficiently details both modes. It uses two tight sentences with no filler, and the backtick parameter references aid 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?

Given no output schema and no annotations, the description still gives enough for correct invocation: mode semantics, parameter meanings, and the main risk/check workflow. Minor omissions like the object parameter's expected format and explicit permanence are acceptable but prevent 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 compensate. It explains ratio (0..1 of current triangles), target_tris as an alternative, angle in degrees for planar, and the mode enum, but leaves the required object parameter implicit.

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

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

The description states a specific verb and resource: reduce the triangle count via decimation. It distinguishes the two modes collapse and planar, making the tool's purpose immediately clear relative to mesh-editing siblings.

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 clearly explains when to use each mode: collapse for reaching a ratio/target, planar for cleaning up subdivided flat surfaces. It also advises checking with compare_view after collapse, though it does not explicitly contrast decimate with alternatives like remesh or repair_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?

With no annotations, the description carries the full burden and does so: it discloses that users are moved to the first material, extras are deleted, repeated slots are joined, and that clean_slots/remove_orphans have destructive side effects. It even covers the edge case of an empty slot still referenced by faces (kept and reported in `faces_without_material`) and the tolerance=0 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?

Dense and front-loaded: the core merge behavior and its rationale come first, followed by side effects and edge cases. It is longer than typical, but nearly every clause adds a distinct behavior; minor tightening is possible 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?

No output schema exists, yet the description states what is returned (count removed, material count before/after) and names the individual counters (`empty_slots_removed`, `unused_slots_removed`, `orphans_removed`). For a destructive, no-annotation, no-output-schema 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%, so the description must compensate, and it explains all four parameters: `names` limits the check, `tolerance` is quantified ('0.01 means 1 percent', 'tolerance=0 merges only exact copies'), and `clean_slots`/`remove_orphans` are tied to their observable effects and output 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?

Opens with a specific verb and resource ('Merge materials that look the same') and immediately enumerates the matching criteria (colour, roughness, metallic, alpha, emission, coat, textures). An agent can distinguish this from list_materials, assign_material_faces, 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 a clear rationale and conditions for use ('Fewer materials means fewer draw calls', 'Textured and procedural materials only merge when their images and node types are the same') and constrains scope via `names`. It does not name an alternative tool or state when NOT to dedupe, 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?

With no annotations at all, the description carries the full burden and does well: it gives units per mode (degrees vs factor), explains axis semantics with a worked example, states the origin default and the [0,1] limits range. It omits whether the operation mutates in place/destructively and says nothing about lock_x/lock_y behavior.

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: the operation and modes come first, then units, then axis semantics, then defaults and the prerequisite. Every sentence adds actionable information 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 an 8-parameter mutation tool with no annotations and no output schema, the description covers units, axis, origin, limits, and the vertex-density prerequisite. The undocumented lock_x/lock_y and the absence of any statement about in-place modification are the remaining gaps.

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

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

Schema coverage is 0%, so the description must compensate, and it explains amount units, axis meaning per mode, origin, and limits. It leaves lock_x and lock_y entirely undefined, which is a real gap for two of the eight 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?

Names a specific operation (deform) and enumerates the four modes (bend, twist, taper, stretch) with the resource being 'the whole mesh'. The mode list distinguishes it from siblings like transform_objects, array, or subdivide.

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

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

Provides a concrete prerequisite ('The mesh needs enough vertices along the axis: subdivide_faces first'), which routes the agent to a sibling tool. It does not, however, state when to prefer deform over transform_objects or the array tools, so exclusions are absent.

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

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

With no annotations, the description carries the full burden and does well: it discloses the side effect of with_children=false (children lose their parent and are reported as `unparented`), the scope expansion of prefix, and the risk mitigation via checkpoint. It stops short of stating reversibility/undo semantics or permission requirements, 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 action and the checkpoint warning, then dense parameter semantics with a worked example, and closes with the sibling routing. 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 destructive tool with no annotations and no output schema, the description covers selectors, cascading behavior, the returned `unparented` list, and the alternative tool. Nothing an agent needs to invoke it safely and 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 compensate and it does: it explains that at least one of names/prefix/lights is required, defines prefix with a concrete example ('bl_light_' removes setup_lighting), enumerates the lights values (added vs all), and explains with_children. All four undocumented parameters are given meaning beyond their names.

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 whole objects') and immediately draws the boundary against the sibling delete_faces ('Use delete_faces to remove a part of a mesh'). An agent can distinguish this tool from the mesh-face deleter 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 (delete_faces) and the condition selecting it, tells the agent at least one selector must be supplied, and adds a prerequisite-style warning ('Take a checkpoint first if you are not sure'). When-to-use, requirement, and alternative are all covered.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the operation's effect (creates openings/holes) and the matching rules for `where`, but says nothing about reversibility, undo/checkpoint interaction, or whether other objects are affected — notable gaps for an unannotated destructive tool.

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

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

Front-loaded with purpose and the sibling distinction, then moves to the filter syntax. Dense but nearly every clause is functional; the `where` enumeration is long but necessary given 0% schema coverage.

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 destructive tool with no annotations and no output schema, the definition covers the selection semantics thoroughly and warns about the whole-object alternative. It is only incomplete on behavioral matters like undo/checkpoint safety and any 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%, so the description must compensate, and it does: it enumerates the `where` keys (normal with angle default 25, x/y/z ranges, box, area, index), explains that null means open, and that {} or null picks everything. Only the `object` parameter is left implicit, which is why this is not 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+resource ('Delete the picked faces of one mesh') and immediately gives the practical outcome (makes openings: doors, windows, open boxes). It explicitly differentiates itself from the sibling tool delete, which removes whole objects, so an agent can route correctly 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?

Names the alternative (delete) and the condition that selects it ('to remove whole objects'), and adds a workflow prerequisite ('Look at mesh_info first to see where the faces are'). It does not spell out when-not to use it beyond that, but the routing guidance is concrete and 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?

No annotations are provided, so the description carries the full burden, and it does disclose the return shape in unusual detail (what counts as changed, the tolerance threshold, the topology and material_slots payloads). It doesn't state whether a missing/expired checkpoint is an error or what happens with the default `name`, 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 sentences, front-loaded with the core answer (what changed), then the detail on payload contents, then a closing usage line. No filler and no repetition of the tool name.

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

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

With no output schema and no annotations, the description does the heavy lifting by describing the returned fields, which is enough for an agent to consume results. The remaining gap is the checkpoint-identification parameter and error behavior when no checkpoint matches.

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 explain `tolerance` meaningfully (metres of movement/size change required to count as changed), but the `name` parameter and its default "last" are never explained — it is only implied that it identifies a checkpoint.

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 operation (diff against a checkpoint) and enumerates exactly what it reports: added/removed objects, moved or resized objects, plus topology and material_slots deltas. This is distinguishable from siblings like checkpoint, rollback, status, or mesh_info, which perform different jobs.

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?

"Use it to review a long session or to see what a tool did" gives clear positive guidance on when this tool applies. It stops short of naming exclusions or pointing at alternatives (e.g. status vs checkpoint vs rollback) for related questions.

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

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

With no annotations, the description carries the full burden and does substantial work: it explains that linked=true shares mesh data, specifies rotation order around world X, Y, Z axes, and defines the default pivot as the copy's bounding-box centre after offset. It still omits side effects such as whether the original is selected, what is returned, and any naming-collision behavior, but the key non-obvious semantics are 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?

Three dense sentences with zero waste. The core action is front-loaded, followed by linked-mesh behavior and rotation/pivot semantics. 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?

Given 6 parameters, 0% schema description coverage, no annotations, and no output schema, the description is only partially complete. It covers the most complex geometric behavior well but does not explain the required `name`, the `new_name` parameter, selection/return behavior, or how this relates to alternative duplication tools.

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

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

Schema coverage is 0%, so the description must compensate. It meaningfully defines offset, linked, rotate_deg, and pivot, but leaves the required `name` parameter and `new_name` entirely unexplained. Partial compensation for half the 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 ('Copy') and resource ('an object') and describes the copy's movement. Clear purpose, but it does not explicitly distinguish itself from nearby duplication-like siblings such as array, radial_array, or mirror, so sibling 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?

Provides no when-to-use guidance and no alternatives. It never says when to choose duplicate instead of array, radial_array, mirror, or other copy-producing tools. Usage is only implied by the parameter explanations.

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

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

With no annotations at all, the description carries the full behavioral burden and does so well: it states the axis convention and triangulation, the world-origin scaling semantics, that the scene is restored afterwards, that the scale is written as node scale, and that max_texture_size rewrites copies inside the GLB while on-disk images stay unchanged. It even hints at return payload structure ('The answer has textures: count, bytes, and name, size and bytes').

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

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

It is long but dense – nearly every sentence adds a distinct fact (units, side effects, compression caveat, texture budget heuristic). The core purpose is front-loaded, though the texture-size discussion drifts toward an aside for a tool that does much more.

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

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

For a 10-parameter mutation tool with no annotations and no output schema, the description covers side effects, scale semantics and return hints well, which is the hard part. It remains incomplete on five parameters and on whether an existing file at `path` is overwritten, which is the main residual risk for an export tool.

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

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

Schema description coverage is 0% across 10 parameters, so the description must compensate, and it only partially does: it explains draco (needs the Draco decoder), influences (bones per vertex), scale (world-origin multiplier with a worked example) and max_texture_size (pixels on longer side, with a size/quality tradeoff). skins, tangents, animations, apply_modifiers and path are left entirely to the bare 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 opening sentence gives a concrete verb and resource ('Write a GLB of the named objects (with children), or of all visible geometry'), so the operation and its scope are unambiguous. It does not name or contrast with the nearby siblings (import_glb, inspect_glb, save_blend), so an agent must infer the boundary from the name alone.

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

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

Usage is implied by the game-engine framing ('the bones per vertex that the game engine reads', 'the game needs the Draco decoder') but there is no explicit when-to-use, when-not-to-use, or alternative routing. An agent can infer it exports for a game runtime, but nothing steers it away from inspect_glb or save_blend.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavior: negative `distance` 'digs in', `offset` is a world vector, `scale` produces a taper, `inset` shrinks the region. However, it says nothing about geometry side effects, whether the source faces are consumed, failure modes, or what the result looks like — gaps that matter for an unannotated 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 front-loaded — the core operation and the primary parameters come first, then examples, then the selector grammar. The `where` clause is lengthy but each key earns its place; only minor tightening is possible.

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

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

For a 6-parameter unannotated mutation tool with no output schema, the description covers five parameters in depth and adds usage and selection guidance. Remaining gap is the absence of any statement about the resulting geometry or side effects, but it is otherwise sufficient to invoke 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, and it does: it explains the meaning and units of `distance`, `offset`, `scale`, and `inset`, and fully documents the `where` selector's keys (normal, angle default 25, world-centre ranges, box, area, index) plus the {} / null default. Only the obvious `object` is left implicit.

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

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

States a specific verb and resource plus the scope ('Extrude the picked faces as one region'), and the mention of `inset`/`scale`/`offset` variants distinguishes it from siblings like inset_faces, subdivide_faces, and delete_faces. An agent can identify the operation without opening the schema.

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

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

Gives concrete typical uses ('raise a roof, make a post, a step, a window recess') and a prerequisite routing hint ('Look at mesh_info first to see where the faces are'). It does not name explicit alternatives or when-not-to-use cases (e.g. inset_faces vs this), 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?

With no annotations, the description carries the full burden and discloses rich behavior: the solid is centred on its depth, plane coordinate conventions are spelled out, `at` shifts the result in world space, and holes are cut using boolean checks with flawed cuts kept and reported in `warnings`. This is well beyond what any structured field provides.

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

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

The description is a single dense paragraph that front-loads the core action, then covers coordinate conventions, positioning, holes/warnings, and use cases. Every sentence contributes necessary information 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 6-parameter 3D modeling tool with no annotations and no output schema, the description covers geometry semantics, hole behavior, and failure reporting well enough for correct invocation. It stops short of explaining the required `name` parameter or the overall return shape, which would help an agent fully understand the result.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for most parameters: `plane` gets detailed coordinate-axis mapping, `at` is explained as a world shift, and `holes` is described as a list of polygons cut through the solid. It leaves `name` unexplained and does not clarify `depth` units or sign, 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?

The description states a specific verb ('extruding') and resource ('closed 2D polygon') to produce a solid, and it explicitly distinguishes this from face extrusion by requiring a closed polygon profile. An agent can tell it apart from siblings like extrude_faces or loft without opening the schema.

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

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

It gives clear positive use cases ('Good for soles, panels, signs, floor plans, outline-based parts'), which helps an agent decide when to select it. However, it does not state when not to use it or name an alternative tool, 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?

With no annotations, the description carries the full burden and largely meets it: it explains grouping logic, how the main group is chosen, that results are folded to max_listed with a count, and the fallback defaults for empty touch/search/near. It does not explicitly state that the tool is read-only/non-mutating, which is the one behavioral trait left to inference.

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 definition before the defaults and follow-up advice, and every sentence carries information. It is dense and some sentences pack multiple clauses (e.g. the size-scaling examples), which costs a bit of readability but 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?

There is no output schema, so the description explains the return shape (nearest part and gap per floating group, tiny_gaps pairs, folding with a count), which is appropriate. It is nearly complete for a six-param tool; the only omission is any explanation of the `names` filter parameter.

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

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

Schema coverage is 0%, so the description must compensate, and it does for five of six parameters: near (2% of the pair diagonal, capped at 0.03 m), touch (0.001 m scaled by part size), search (1 m scaled), ground_z, and max_listed. The `names` parameter is never mentioned, leaving one gap in an otherwise strong compensation.

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 parts that hang in the air') and immediately defines the concept operationally: meshes that touch/overlap form groups, the group standing on ground_z (or largest) is the main one, everything else is floating. An agent can distinguish it from siblings like check_contacts, ground, or move_to_contact without opening the schema.

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

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

Gives explicit timing and follow-up ('Run it after assembling a model, then fix with move_to_contact or attach'), naming the concrete remediation siblings. It lacks an explicit when-not-to-use or a contrast against check_contacts, so it falls just 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?

With no annotations, the description carries the full burden and does substantial work: it discloses the IoU optimization objective, the guard that refuses moves hiding parts, checkpoint creation ('before_fit') with rollback, background-job timeout behavior via wait, and rejection reporting. It doesn't state whether the operation is destructive to existing transforms or whether it fails atomically, leaving a small gap 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?

Front-loads the core purpose and 'when' well, but the body is dense, runs long, and mixes several concerns (scaling syntax, guard mechanics, rollback, jobs) in an undifferentiated block. Every sentence is substantive, but structure and segmentation would help readability.

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 18-param, no-annotation, no-output-schema tool, the description covers the dominant concepts an agent needs: purpose, metric, which views/refs, size specification, guard behavior, and async job handling. Missing detail on numerous tuning parameters and exact returned fields (only partially noted: rejected moves, visible_share before/after) keeps it short of 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% across 18 params, so the description must compensate and does for several key ones: references, names, height_m/width_m (including the dict-per-view form and precedence rule), mirror_pairs, tune, max_hide/visible_share, and wait. However, many numeric tuning params (step_m, scale_step, threshold, iterations, max_tilt, tilt_deg, max_shift, time_limit, size) are undocumented, leaving a gap given the very low schema coverage.

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

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

States a specific verb+resource ('Move, scale and tilt parts') and distinguishes from shape-editing siblings by explicitly saying it 'fixes placement and proportions, not shapes.' The optimization target (world-registered IoU over all views as measured by compare_view) is named precisely.

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?

Explicit when-to-use ('when the forms are roughly right') and states what it does not do (shapes). It anchors the metric to compare_view, giving the agent an alternative/companion tool for interpreting results. No important exclusions left 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?

No annotations exist, so the description carries the full burden. It usefully discloses scope behavior (all top-level objects when names is empty), which is real behavioral context. However, it never states that this is a mutating operation, whether it is reversible, or how it interacts with grouped/child objects, leaving the safety profile implicit.

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, with the core transformation front-loaded before the alternative-tool routing. Nothing redundant.

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 2-parameter, no-output tool, the description covers purpose, scope default, and the sibling alternative. Remaining gaps (coordinate frame, effect on non-top-level objects) are minor.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains that an empty names list means all top-level objects and defines z as the target height of the lowest point. This adds genuine meaning beyond the bare number/null schema, though the coordinate frame (world vs. parent) is unstated.

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

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

States a specific verb (move) and resource (objects) plus the exact transformation applied (lowest point at height z), and explicitly names the sibling tool it is not (place_on). An agent can distinguish it from place_on, move_to_contact, and transform_objects 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?

Provides an explicit alternative and the selecting condition: 'Use place_on instead when the floor is another object or not level.' This is exactly the when-not guidance that routes the agent correctly.

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

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

No annotations are supplied, so the description carries the full burden. It usefully discloses a return-side trait ('list the new objects with their world sizes'), which tells the agent the call adds objects and reports their scale. However it omits whether import replaces or appends to the scene, error behavior for malformed files, and unit/scale handling.

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

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

A single front-loaded sentence with no filler: action first, artifact type second, result last. Every clause earns its place and nothing is padded.

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

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

For a one-parameter import tool with no output schema and no annotations, the description covers the core action and roughly what is returned. It is still missing path-format guidance and whether the import mutates the existing scene, which an agent would need 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 description coverage is 0% and the single 'path' parameter is undocumented in the schema, so the description must compensate. Saying 'GLB or glTF file' hints that path targets a file, but it never states whether the path is absolute or relative, accepted extensions, or how it resolves, leaving the one required parameter underspecified.

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 (import) and resource (GLB or glTF file), and the verb clearly separates it from export_glb and inspect_glb among the siblings. It also notes the outcome of listing new objects, so an agent can identify the tool without opening the schema, though it never explicitly names the contrasting siblings.

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

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

Usage is only implied: an agent can infer this is the tool to call when bringing an external GLB/glTF asset into the scene, but there is no statement of when to prefer it over inspect_glb, nor any prerequisites (e.g. file must exist on disk). No exclusions or alternatives are given.

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

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

With no annotations, the description carries the full burden and does well: it discloses the empty/default thickness (0.02 m) and its adaptation to small objects (<0.3 m), the negative-depth convention as a recess, and per-face vs grouped execution. It stops short of stating whether the operation is destructive, reversible, or requires any auth/side-effect warnings.

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

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

Front-loaded with the core verb, and the dense `where` documentation is warranted given 0% schema coverage. The prose is packed but each clause adds needed selection or behavioral detail; the single multi-line paragraph is 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 5-param, no-annotation, no-output-schema mutation tool, the description is nearly self-sufficient: parameters, defaults, and the selection DSL are covered. The only unanswered question is the return/result behavior and any effect on the pre-existing mesh.

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

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

Schema coverage is 0%, so the description must compensate, and it does: thickness, depth, and individual are all explained with defaults and semantics, and the complex `where` object is fully documented (keys, formats, null/missing behavior). Only `object` is left implicit, which is self-evident.

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 ('Inset the picked faces'), immediately distinguishing it from sibling face tools like extrude_faces or subdivide_faces. It also clarifies the core modifiers (thickness, depth, individual) in the first two sentences.

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

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

Gives clear operational context: default thickness behavior, sign convention for depth, and the meaning of individual. It also prescribes a prerequisite workflow ('Look at mesh_info first'). It does not, however, explicitly contrast when to choose inset over extrude_faces or subdivide_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?

No annotations are provided, so the description carries the full burden, and it does substantial work: it discloses the exact return contents and the specific warning conditions (missing normals/UV, oversized or non-power-of-two textures, duplicate node names). It never explicitly confirms the operation is read-only/non-mutating, but the phrasing implies inspection only.

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

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

Front-loaded with the output enumeration, then a short rationale sentence. The field list is long but each item earns its place by telling the agent what it will learn; no filler 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 2-parameter read-only inspection tool with no output schema and no annotations, the description effectively serves as the output contract by listing returned data and warning triggers. The remaining gap is the undocumented max_texture parameter.

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

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

Schema description coverage is 0% for 2 parameters, so the description must compensate. It only implicitly identifies 'path' ('the file you exported') and says nothing at all about 'max_texture' or its 2048 default, leaving the agent without guidance on a parameter that changes the reported result.

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

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

States a specific verb and resource ('Read a GLB file without Blender') and enumerates exactly what is extracted: triangles, vertices, materials, textures with sizes, extensions, file size and warnings. The 'without Blender' framing clearly separates it from import_glb and the mesh-inspection siblings.

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 usage context with rationale: 'Run it on the file you exported, because that is what the game loads.' That tells the agent when this tool is the right one, but it names no alternative (check_mesh, mesh_info, check_game_ready) and gives no exclusions.

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

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

With no annotations, the description carries the full burden and does well: it discloses that cancel stops the job while the scene retains the changes the job already made, and routes the user to rollback for undo. It omits the exact return format/progress shape and any indication of whether polling is required, which keeps it out of the top band.

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 tool's purpose and enumerates state outcomes compactly, then handles the job-id origin, the no-arg listing behavior, and cancellation/undo. Dense but each sentence carries information; 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 two-parameter, no-annotation, no-output-schema tool, the description covers purpose, both parameter behaviors, the lifecycle that produces job ids, and the cancel/rollback side effect. It is nearly complete, lacking only detail on the returned progress/result payload.

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 parameters are bare (no descriptions), so the description must compensate. It does: `job` is defined by its absence (lists all session jobs) and `cancel=true` is defined as stopping the job. Both parameters gain meaning beyond the schema.

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

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

States a specific noun+behavior — reporting the state of a background job — and enumerates the possible outcomes (running/progress, done/result, failed/error). An agent can tell what it returns. It does not, however, differentiate itself from the sibling `status` tool, which is the one thing that could confuse selection.

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

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

Explains the trigger condition: long tools that exceed their `wait` seconds return a job id, which you then poll here; omitting `job` lists all session jobs. It names the alternative `rollback` for undoing a canceled job's changes. No explicit when-not-to-use, but the context is clear.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavioral traits: how a radius-0 profile yields a solid, how close=true closes the loop to produce a ring, and how angle<360 produces a wedge. It stops short of describing defaults for cap/segments/axis or whether it creates a new scene object, but the core operation semantics are unusually well explained.

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?

Four tight sentences, front-loaded with the core operation before the profile format and the shape outcomes. The parenthetical shape examples (vase, donut, wedge) earn their place by anchoring abstract parameters to concrete results, with little 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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the pivotal geometry but leaves cap, segments, axis, and at unexplained, so an agent cannot fully reason about the call. Adequate but with clear gaps given the tool's complexity.

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

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

Schema coverage is 0%, so the description must compensate, and it does document the most consequential parameters: the [radius, height] point format, close, and angle. However, at, axis, cap, segments, and name are undocumented in both schema and description, leaving half the surface unexplained.

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

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

States a specific verb and resource ('Spin a profile around an axis') and immediately grounds it with the profile format, so an agent knows exactly what operation this performs. It does not explicitly contrast with nearby siblings like sweep, loft, or extrude_profile, which also turn profiles into solids, 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?

The description explains geometry outcomes (solid vs tube vs ring vs wedge) but never states when to choose lathe over sweep, loft, extrude_profile, or radial_array, nor any prerequisite for calling it. There is implied usage via shape examples but no explicit selection guidance.

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

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

With no annotations, the description carries the full burden. It does disclose real behavior: ends are rounded, geometry stays inside the path, and radii can be uniform or per-point. It omits whether the object is created/modified, permission or scene-state requirements, and what the 'apply' flag actually does.

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 core action and technique, and reasonably tight. The use-case list adds selection value rather than pure padding, though it is the softest sentence.

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 annotations, no output schema, and 0% schema description coverage over 6 parameters. For a mesh-creation tool the description explains the geometry concept well but leaves too many parameter semantics and mutation behaviors undocumented for an agent 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 description coverage is 0% across 6 parameters, so the description must compensate. It only clarifies points (polyline of world points) and radii (one per point or one for all); name, apply, sides, and subdivisions are left completely unexplained in both the schema and the description.

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

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

States a specific verb and resource: 'Make a smooth tube along a polyline of world points', plus the technique (Skin plus Subdivision) and example uses. It is clearly distinguishable from generic siblings, but it never explicitly contrasts itself with close relatives like sweep, loft, or extrude_profile.

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 example list ('arms, legs, tails, tentacles, branches') implies the intended context, so an agent can infer when to reach for it. However, there is no explicit when-not-to-use guidance and no named alternative against sweep or loft, which is the real selection risk here.

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

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

With no annotations, the description carries the full burden and does well: it discloses that object names resolve to bounding-box centres, that the two named objects never block the ray, and that the first blocker is returned. This is exactly the kind of caveat an agent needs to interpret results, though the return value when nothing blocks the ray is unstated.

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

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

Three tight sentences front-loaded with the core question, then parameter semantics, then the blocking caveat and usage. 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 two-param query tool with no output schema, the description covers inputs, the blocking rule, and the primary return. The only gap is the outcome when the ray is unobstructed, which is left to inference.

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

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

Schema coverage is 0%, so the description must compensate, and it does: both parameters are explained as either a world point or an object name (bounding-box centre). The array shape for a world point is left implicit, but the semantic meaning is fully conveyed.

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 predicate (visibility between `a` and `b`) with the resource form (world point or object name). It is clearly distinct from the map-level siblings (sightline_map, viewshed), though it never names them explicitly to sharpen the boundary.

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?

'Use it for sight lines, cover and corridors' gives implied usage context, but there is no when-not guidance and no routing to alternatives like raycast or sightline_map despite the crowded sibling set.

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

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

No annotations are provided, so the description carries the full burden. It never states that this is a non-mutating read, whether the armature must be posed/selected first, what happens if the name is invalid, or the ordering of results.

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

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

It is short with no padding, but it is a sentence fragment with no verb, so the key action is not front-loaded. Efficiency comes at the cost of grammatical completeness.

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 no annotations, the description is the only source of truth. Naming the returned fields (parent, world head/tail, length) is a genuine plus, but identifier format, ordering, and read-only behavior are all missing for a tool whose sole input is undocumented.

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

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

Schema coverage is 0% and the single parameter 'armature' is undocumented in the schema. The description implies the parameter identifies an armature but never says whether it is an object name, a UUID, or an index, so it only partially compensates 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 fragment 'Bones of an armature with parent, world head and tail, length' identifies the resource (bones) and the scope (of an armature), and the name supplies the list verb. However it reads as a description of returned fields rather than a statement of what the tool does, leaving the action implicit.

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

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

There is no indication of when to use this versus siblings like create_armature, bind, transfer_weights, or check_weights. The agent must infer from the name alone that this is a read/inspection step before posing or binding.

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

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

No annotations are provided, so the description carries the burden; it discloses the full field set returned and explains the `preset` flag's provenance (bl_light_* lights created by setup_lighting), which is real behavioral context. It does not state explicitly that the operation is non-mutating, though 'List' strongly implies it.

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, front-loaded with the returned-field inventory before the preset note. The trailing sentence about removing lights is useful routing but slightly drifts from the tool's own behavior.

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

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

With no output schema, the description compensates by enumerating the returned fields, and with no annotations it clarifies the preset semantics. Nothing essential for calling a zero-parameter listing tool is missing, though a note on ordering/scene scope would make it 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?

The tool takes zero parameters, so there is nothing for the description to document and the baseline is 4. The mention of 'names, prefix or lights' refers to the sibling delete tool's arguments rather than this tool's inputs.

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

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

States a specific verb and resource ('List every light in the scene') and enumerates exactly what is returned (name, kind, place, aim/direction, power, colour, kind settings, preset flag). This lets an agent separate it from add_light, setup_lighting, set_world and delete 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?

The description implies a read/inspect use case and points to `delete` (with names, prefix or lights) for removal, which gives one clear when-not signal. It never says when to prefer this over sibling inspectors like scene_tree or list_materials, so guidance is only partially covered.

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

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

With no annotations, the description carries the burden and does so well: it explains that procedural nodes are not exported to glTF and are flagged `not_exported`, what faces_without_material counts, that alpha_mode mirrors glTF alphaMode written by export_glb, and that render_method is the EEVEE draw mode. It never explicitly states this is a read-only, side-effect-free call, which is the remaining gap.

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

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

Dense but largely front-loaded: the all-materials behavior leads, then the node/face caveats, then the single-material mode. Some sentences are long and pack field lists that read like schema rather than guidance, 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?

No output schema and no annotations, yet the description enumerates the return contents in both modes, which is the key thing an agent needs. Minor omissions remain (read-only status, whether users/faces counts could be expensive on large scenes), but overall adequate for a one-param read tool.

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

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

Schema coverage is 0% and the single parameter is nullable with no description, so the description must compensate — and it does, fully spelling out the two behavioral modes: without `name` returns every material's summary, with `name` returns that one material's detailed card including texture paths, normal map colour space, and per-object face counts.

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

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

States a specific verb (list) and resource (materials) and immediately enumerates the returned fields, so the agent knows exactly what it gets. It implicitly separates itself from mutation siblings like set_material and assign_material_faces, though it never names them as alternatives for the read task.

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

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

Gives clear context: use it to find look-alikes before dedupe_materials, and fix faces_without_material via assign_material_faces. It also explains the two invocation modes (no `name` = all materials, with `name` = one material's card). No explicit when-not-to-use, but routing is strong.

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

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

No annotations exist, so the description carries the burden. It usefully discloses that sections are ordered along the axis, that roundness 2 = ellipse and 4 = rounded box, and implies closure — but it never explains the effect of segments, subdivisions, caps:false, or axis defaults, which are behaviorally significant for a generator.

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?

Roughly four front-loaded sentences with no filler: the definition leads, the section grammar follows, then use cases and the alternative. Slightly dense inline JSON, but 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 6-parameter generator with no annotations and no output schema, the description covers the core section format well but omits the tiling/closure controls (caps, segments, subdivisions) an agent needs to call it correctly. Adequate but with a clear gap.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate. It does an excellent job on 'sections' (at/size/roundness semantics), but leaves name, axis, caps, segments, and subdivisions completely undefined, so half the interface is undocumented.

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

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

States a specific verb and resource: 'Make a closed body from cross-sections you give as numbers along an axis.' It defines the section object and names the sibling loft_from_masks as the distinct path, so an agent can separate it from lathe/sweep/revolve-style 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?

Explicit routing: 'Good for torsos, heads, bottles, columns' gives the target use case, and 'With a front and a side image of the form use loft_from_masks' names the alternative and the condition that selects it. Nothing is left to inference.

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

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

With no annotations provided, the description carries the full behavioral burden. It explains the core geometry behavior in detail: per-band cross-sections, part selection semantics, side_faces orientation, z_range fractions, roundness shapes, and flat end bands. However, it does not disclose side effects such as whether it creates a new object, replaces existing geometry, 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?

The description is dense but front-loaded with purpose and core behavior. Every sentence adds useful technical detail, though the long single paragraph could be structured more readably with parameter-focused bullets.

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

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

The tool is complex: 13 parameters, no annotations, no output schema, and 0% schema description coverage. The description covers core geometry but omits return values and leaves many optional parameters unexplained, so an agent still has significant gaps 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% across 13 parameters, so the description must compensate. It meaningfully explains part, side_faces, z_range, and roundness, but leaves at, name, height_m, bands, segments, threshold, and subdivisions undocumented. For a 13-parameter tool with zero schema descriptions, this is only partial compensation.

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: 'Build one rounded body from a front and a side silhouette image.' It also distinguishes itself from the sibling tool loft by saying 'with numbers instead of images use loft.' An agent can tell exactly what this tool produces and when it applies.

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

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

It explicitly names the alternative tool for numeric input ('with numbers instead of images use loft'), which is a clear routing condition. It also clarifies key mode choices such as part=largest vs part=extent and side_faces orientation, giving the agent actionable guidance.

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

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

With no annotations, the description carries the full burden and does: it states the camera is created or updated and becomes the scene camera, lists the returned fields (location, rotation, look_at, fov_deg, IoU before/after), and discloses the async behavior (after `wait` seconds the result is a job id for job_status). The occlusion/alpha threshold behavior and the symmetric-model front/back caveat are also surfaced.

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 the alternative, then dense operational detail. Nearly every sentence earns its place, though the middle paragraphs are telegraphic and a few clauses (e.g. the fov_deg/distance trade-off) are terse enough to risk misreading.

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-parameter, long-running optimization tool with no annotations and no output schema, the description supplies return fields, init heuristics, resolution budget and job handling. Only the unmentioned time_limit and names parameters keep it from being 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 coverage is 0% for 11 parameters, so the description must compensate and largely does: it explains init, reference ('give the whole original photo, not a crop'), fov_deg, ground_z, size, iterations, camera, wait and background-job semantics. It never explains time_limit or names, leaving two parameters 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?

Opens with a specific verb+resource ('Find the camera that shows the model like a perspective photo') and immediately names the sibling it is not for flat orthographic views (compare_view). The optimization goal — tuning position, rotation, roll and FOV to match the silhouette — is unambiguous.

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

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

Explicitly routes orthographic cases to compare_view and silhouette-ambiguity checks to overlay_reference, and specifies start conditions ('init' dict, else active perspective camera, else 8 azimuths x 2 elevations) plus when the call degrades to a background job. Named alternatives and conditions make the selection decision inferable.

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

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

With no annotations, the description carries the full burden. It discloses output-oriented behavior, including notes like 'scale not applied' or 'negative scale', but does not state that this is a read-only measurement operation, nor does it mention permissions, side effects, or mutation risk.

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 three sentences and front-loads the returned metrics before usage guidance and the sibling alternative. It is compact and free of obvious filler, though the opening list is more output inventory than purpose statement.

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 and no annotations, so the description must cover both behavior and return values. It lists several return fields and usage context, but omits the required `names` input semantics and does not explain whether results are per object or how they are structured.

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 sole required parameter `names`, and the description never mentions the parameter, its multiplicity, or what object names it expects. It does not compensate for the missing schema documentation.

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 measured quantities (world-space size, min, max, center, origin position, rotation, scale) and explicitly distinguishes the tool from measure_profile. It implies measuring an object, but lacks an explicit verb+resource statement such as 'Measure one or more objects'.

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 context with 'Use it after every move' and names the alternative for reference images: measure_profile. It does not state when not to use this tool or any prerequisites, but the primary usage 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?

With no annotations, the description carries the full behavioral burden. It discloses the return structure (width, edges, runs, filled width per band), the height mapping, grid behavior with metric labels and coordinates, region zoom, and file output. However, it does not explain the threshold or bands parameters and gives no permission or rate-limit context (likely 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?

The description is dense but front-loaded with the core purpose and return details. It is appropriately sized for a complex measurement tool, though some clauses could be tightened and the line break after 'The image' is awkward.

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 and no annotations mean the description must cover behavior and returns, which it largely does by explaining bands, coordinates, grid, region, and out. For a complex 8-parameter tool, the remaining gaps around threshold, bands, and reference format keep it from being fully complete, but the core invocation is clear.

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