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

With no annotations, the description carries the behavioral load and does well: it discloses that the effect is a live, editable Geometry Nodes modifier ('Roxy Damage') rather than a destructive bake, describes what geometry physically changes, and names make_game_asset as the step that bakes it into the normal map. It doesn't cover permissions, undo, or applicability preconditions (existing convex edges), which keeps it at 4.

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 compact sentences, front-loaded with the core purpose, then mechanism/workflow, then the exclusion. Efficient overall, though the first sentence is dense with descriptive clauses that could be trimmed.

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

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

For a mutation tool with no annotations and seven parameters, the description covers purpose, the modifier mechanism, the baking workflow, and exclusions adequately. It doesn't describe the returned state or how the added modifier interacts with manage_modifiers, leaving minor gaps.

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

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

Schema description coverage is high (86%), so the schema already documents seed, size, depth, amount, objects, spacing and edge_angle. The description adds no parameter-level syntax or format detail beyond restating the wear concept ('wear shading follows the chips'), so the baseline 3 is appropriate.

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

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

States a specific verb+resource: it adds chipped edges as real geometry (flakes, beveled rims, wear shading) via a 'Roxy Damage' modifier. An agent can tell this apart from additive detail tools like add_surface_detail or add_masonry, and the explicit 'Not for clean new products' scope note seals 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?

Gives clear context for when it applies ('wood, stone, concrete, painted props') and a scope exclusion ('Not for clean new products'), plus the downstream workflow with make_game_asset. It stops short of naming the specific alternative an agent should reach for when the exclusion applies, so it's just shy 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 burden and does disclose key side effects beyond the schema: it creates a live 'Roxy Masonry' Geometry Nodes modifier plus a '<name>_Mortar' child object, and that every unit varies in depth and tone. This is genuinely useful behavioral context. It stops short of stating reversibility or how it treats pre-existing geometry, so it is strong but not exhaustive.

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

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

Front-loaded with the core purpose, then side effects, then workflow hooks in three dense sentences with little waste. The telegraphic style ('chips the arrises') is efficient but slightly jargon-heavy, keeping it just short of a 5.

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

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

For an 11-parameter tool with no output schema and no annotations, the description covers purpose, generated side effects (modifier + child object), and downstream tool chaining adequately. It does not explain the return value or how it handles existing meshes, but the essentials for correct invocation are present.

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

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

Schema description coverage is 91%, so nearly every parameter (up, along, joint, stagger, course_height, etc.) is already well documented in the schema with real-world value guidance. The description adds only implicit meaning (e.g. 'joints are real gaps with a mortar bed behind' relates to joint/mortar_depth) but no syntax beyond the schema, so the baseline holds.

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 (add) and resource (masonry), then precisely defines what that means: real bricks, blocks, stone courses or tiles with real mortar gaps. This clearly distinguishes it from siblings like add_planks (wood) or create_cushion, and names the concrete surfaces it targets (walls, chimneys, floors, steps).

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 contextual cues about what surface types this produces (walls, chimneys, floors, steps) and names follow-up tools (add_damage chips the arrises; make_game_asset bakes it), which implies a workflow. However, it never explicitly states when to choose this over alternatives such as add_planks or add_surface_detail, nor any exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden, and it does disclose non-obvious behavior: exact booleans hide the cutter, and the stack is auto-ordered (booleans/mirror/solidify before bevel/subdivision). That is genuine added value, but it omits failure modes, reversibility/undo behavior, and how conflicts with existing modifiers are handled.

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 action, and every clause earns its place by naming concrete default behaviors. The parenthetical is dense but compact.

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 defaults and ordering behavior adequately. It is still missing sibling routing and error/reversibility context, leaving some gaps an agent would want.

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

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

Schema coverage is 60% and the params field already documents shortcuts, angles, and accepted types. The description adds the default behaviors applied per modifier type but does not map meaning onto the object/name/apply parameters beyond what the schema states, so it sits at the baseline.

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

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

The description states a specific verb+resource (add a modifier) and adds the distinguishing feature of quality defaults with auto-ordering. However, it never differentiates from the sibling manage_modifiers, so an agent cannot tell from the text alone which tool to pick for the same 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?

There is no explicit when-to-use guidance, no exclusions, and no mention of the alternative manage_modifiers. 'Quality defaults' implies a use case but leaves the agent to infer when to prefer this over manually managing modifiers.

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

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

With no annotations, the description carries the full burden and does a solid job: it discloses that a live, editable Geometry Nodes modifier ('Roxy Planks') is created, that per-board material values ('roxy_board') drive tone variation, that bevel/chips/weathering apply per board, and that make_game_asset later bakes gaps into the normal map. It does not state whether the input solid is replaced or preserved, nor any selection/permission prerequisites, which keeps it short of a 5.

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

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

Front-loaded with the core transformation, then supporting behavior, with no filler sentences. The trailing list of target artifacts is slightly dense but each clause (modifier name, roxy_board, baking) carries information an agent needs.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, the description covers role, downstream interaction with make_game_asset, and per-board behavior. Remaining gaps are minor: what object state results after the call and any prerequisites for the solid input.

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 83%, so the schema already documents gap, axis, offset, board_width and objects. The description only implicitly references gaps ('with gaps') and adds no syntax, units, or defaults beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource: turning a solid (box, lid, extrusion) into real boards/staves with gaps. The output artifacts (crates, chests, floors, fences, barrels, doors) make it clearly distinguishable from siblings like add_masonry or add_surface_detail 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 list of use cases (crates, chests, floors, fences, barrels, doors) gives clear context for when this is the right tool, and it notes the relationship to make_game_asset. However it never explicitly names a sibling alternative or states when NOT to use it versus e.g. add_masonry 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 disclose non-obvious mechanics: screws/rivets are snapped onto the real surface and parented to the object, panel lines are real grooves affected by the object's bevel modifier, and vents are a live boolean. This is meaningful behavioral context an agent could not get from the schema. It still omits prerequisites, whether the operation is destructive/reversible, and failure 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?

Two compact sentences: the first frames the purpose, the second front-loads the three implementation behaviors. Every clause carries information, though the opening rationale is slightly motivational rather than operational.

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 14-parameter tool with no output schema and no annotations, the description covers the behavior of each detail kind and the schema covers the parameters well. The main gaps are prerequisites and any indication of return/error behavior, but these are minor against the rich schema.

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

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

Schema description coverage is 86%, so the schema already documents nearly every parameter (axis, side, count, depth, width, length, margin, offsets, positions, material). The description only reinforces the kind-to-mechanism mapping (seams/fasteners/vents), adding little beyond the schema's own enum documentation. Baseline 3 is appropriate.

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

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

The description makes clear that this adds manufactured surface detail (seams, fasteners, vents) and names the four mechanisms, which map to the kind enum. It never states the verb explicitly or distinguishes itself from nearby siblings like add_damage, add_planks, or add_modifier, so an agent must infer the 'add detail to an existing surface' framing.

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

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

There is no when-to-use or when-not-to-use guidance, no prerequisites (e.g., object must be an existing mesh), and no mention of alternatives. Usage is only implied by the word 'secondary detail' in the opening clause.

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 load. It usefully discloses output behavior ('Each issue comes with a fix hint') and its read-like nature ('Find'), but says nothing about side effects, permissions, or whether it mutates the scene. It adds some output context but leaves the safety/mutation 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?

The purpose clause is front-loaded before the dense but scannable issue list, and every entry earns its place as a concrete detectable defect. It is slightly list-heavy but appropriately sized with no wasted 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 read-only analysis tool with no output schema and no annotations, the description adequately conveys what is detected and that fixes are suggested. It is incomplete on how it differs from sibling review/inspection tools and on the semantics of two of its three parameters.

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

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

Schema coverage is only 33%: 'objects' is documented in the schema, but ground_z and check_intersections have no field descriptions. The description mentions 'intersecting parts' and 'floating or sunken parts', hinting at those parameters, but never explains their meaning, defaults, or the object-scoping syntax, so it fails to compensate for the coverage gap.

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

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

The description states a specific verb (find/analyze) and resource (model quality problems) and enumerates the concrete issues it detects, from flipped normals to missing lights. This is far more than a restatement of the name. It does not, however, distinguish itself from nearby QA siblings such as review_model, inspect_object, or check_contacts, which an agent could easily confuse it with.

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

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

Usage is only implied by the list of things it checks; there is no explicit 'use this when' and no naming of alternatives like review_model or inspect_object. An agent can infer this is a diagnostic pass, but it gets no guidance on when this tool is the right choice versus the adjacent inspection 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?

With no annotations, the description carries the full burden. It does disclose one behavioral trait — that it returns a curve check for speed spikes and loop seams — which is genuinely useful since there is no output schema. However, it never states that this is a mutating operation, what happens to pre-existing keyframes/actions, or any permission/scope constraints, which is a significant gap for a 7-parameter authoring tool.

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

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

Two tight sentences, front-loaded on capability, with the return-value note appended. No filler, though the parenthetical list of easing libraries is somewhat brag-like rather than operational.

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?

Because there is no output schema, the description's one-line mention of the curve check is valuable and partially fills that gap. But for a 7-parameter, no-annotation mutation tool, the definition omits usage context, mutation semantics, and sibling differentiation, leaving it only minimally 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 86%, so the schema already documents bone, keys, loop, action, property, and relative including an inline ease example. The description adds no parameter meaning beyond this, so the baseline 3 is appropriate; it does not compensate for or extend the schema.

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

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

The description names a specific action (keyframing) with a distinctive attribute (per-segment designer-grade easing via Easy Ease, cubic-bezier, back/bounce/elastic) and previews a return artifact (curve check). That is enough for an agent to understand the tool builds animated keyframes, but it never distinguishes itself from the nearby siblings animate_preset, check_animation, or rig_character, which overlap in theme.

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

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

There is no when-to-use or when-not-to-use guidance and no routing to alternatives. Given siblings like animate_preset (presumably canned animations) and check_animation, the description should say when to hand-author keyframes with this tool versus using a preset, but it offers nothing.

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

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

With no annotations, the description carries the full burden, and it does disclose one meaningful behavior: each preset becomes its own action/clip (a state-creating side effect). However, it omits anything about overwriting existing actions, naming/return behavior, or prerequisites, which is thin for a 12-parameter tool.

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

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

Two tight sentences, front-loaded with the core purpose and followed by the useful 'preset becomes its own action (clip)' detail. No filler, though the phrase 'based on the principles of animation' is somewhat marketing-flavored.

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 12-parameter mutation tool with no annotations and no output schema, the description is too sparse. It explains none of the parameter interplay (ease, amount, duration, overshoot), the rig_prop bone targeting, or what the generated clip looks like, leaving major gaps.

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

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

Schema description coverage is only 50%, and the description adds no parameter-level meaning at all — it never mentions axis, bone, ease, amount, overshoot, or anticipation. It leaves half the parameters potentially undocumented in both places, failing to compensate for the coverage gap.

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

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

The description conveys a specific purpose: applying animation-principle-driven preset motions to props (lid, door, drawer, lever, fan, pickup), and notes the output is a clip. It implies a preset-based shortcut but never names the `animate` sibling or contrasts preset-driven work with manual animation.

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 by 'the quickest way to a lively lid, door...' which suggests using this for fast, ready-made motions. There is no explicit when-to-use vs the `animate` sibling and no exclusions or prerequisites, leaving the agent to infer 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 must carry the full behavioral load. It usefully discloses that identical specs are shared automatically, no UVs are needed, and reusing a name updates everywhere — real behavioral context. But it omits key mutation semantics: which objects are valid targets, whether it overwrites existing materials, permission/rate concerns, or what happens on name collision vs. reuse.

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 with a coherent arc: capability → sharing behavior → usage preference. But the first sentence is a dense list of material features that reads more like marketing copy than an operational statement, and the description never front-loads what the tool actually does to an object.

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 27-parameter mutation tool with no annotations and no output schema, the description covers material semantics reasonably but leaves essential gaps: it doesn't state the core action (applying to objects), doesn't mention that this is a write/mutating operation, and gives no output/return expectations. It is minimum-viable but not complete.

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

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

Schema description coverage is 89%, so the schema carries most parameter meaning and a baseline of 3 applies. The description adds qualitative intent — 'prefer presets over plain colours', material mixing guidance — which is beyond-schema, but the two bare parameters (metallic, roughness, emission_strength) and the interplay of preset/name/reuse/source are not clarified.

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 describes material qualities (PBR, procedural detail, weathering) and gives application guidance, but never states the actual verb+resource of the tool — that it assigns/applies a material to object(s). The parameter 'objects' is the only hint of the action. An agent must infer the core purpose from context rather than reading it directly.

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 offers actionable preferences: 'Prefer presets over plain colours' and 'real objects mix materials' with concrete examples (wooden top + metal legs). However, it never names alternative tools or states when NOT to use this one — notably it doesn't point to add_surface_detail, add_damage, or uv_unwrap, which are close siblings in the same space.

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 does disclose one meaningful behavioral trait: attachment uses measured closest points, never guessed coordinates, which is a trust-relevant guarantee. However it does not mention that the operation mutates the scene, that oversized moves are refused (max_move), that overlap is refused by default, or what happens on failure — all of which live only in the schema.

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

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

A single tight sentence with zero filler, and the operative constraint (measured points, no guessing) is front-loaded alongside the sibling reference. It is appropriately sized for a one-line pointer, though it is arguably terse for a tool with three distinct modes.

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 three modes, no annotations, and no output schema, the description is minimal but not deficient: the schema fully documents parameters and the description supplies the workflow link and the no-guessing guarantee. It still omits what the tool returns/modifies and the refusal behaviors that an agent acting without annotations would benefit from knowing.

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

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

Schema description coverage is 100%, so the schema already documents all eight parameters, including mode semantics, gap behavior per mode, direction, target, and safety limits. The description adds no parameter-level meaning beyond that, which is the expected baseline-3 case when the schema does the heavy lifting.

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

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

The description states a specific action (attach a detached part to close the gap) and explicitly ties it to the sibling check_contacts, so the agent knows this consumes measured contact data. It stops short of naming the resource directly ('attach_part' infers it) and does not distinguish its three modes, which only the schema covers.

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 implies a workflow prerequisite ('the gaps check_contacts measured'), which tells the agent to run check_contacts first, and the target parameter warns 'do not just accept the nearest part.' But there is no explicit when-to-use-this-vs-alternatives statement, no mention of when to skip it, and no guidance on choose-move-vs-extend-vs-conform beyond the schema.

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 that results come back per step and that image-producing tools lose their images, but says nothing about ordering/parallelism guarantees, how errors surface when stop_on_error is false, or the exact return shape per step. Adequate but with clear gaps for a meta-execution tool.

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

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

Two tight sentences with zero filler; the core capability is front-loaded and the caveat follows immediately. Every clause earns its place.

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

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

No output schema exists, yet the description does mention the per-step result granularity, which is the main thing an agent needs. Remaining gaps — error handling under stop_on_error=false and result ordering — are modest for a 2-parameter 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 50%; the operations array format is documented in the schema itself ('command names and params are the same as the tools'). The description adds only a soft example ('all the parts of a chair') and never addresses stop_on_error semantics, so it does not compensate for the uncovered half beyond baseline.

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

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

States a specific verb (run) and resource (many tool calls) with a clarifying example ('all the parts of a chair'), and the meta-tool nature makes it unmistakable among the concrete modeling siblings. An agent immediately knows this is the multi-call batching entry point.

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

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

Gives an explicit exclusion — 'Not for look/render_image (their images are dropped)' — which is exactly the kind of when-not guidance that prevents wasted calls. It does not, however, state when batching is preferable to sequential calls or what the alternatives are, 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, the description carries the full behavioral burden. It says what it detects but not that it is read-only/non-destructive, what result it produces (a list of hitches? a pass/fail?), or how many objects it will scan. For a diagnostic tool with zero annotation coverage this is a notable 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?

One sentence, front-loaded with the verb and the finding, with zero filler or 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?

For a one-parameter, optional-arg check tool with no output schema, the description is minimal but functional. It omits the default scope when 'objects' is null and gives no hint of the result shape, which a no-output-schema tool should ideally supply.

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

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

Schema description coverage is 100% for the single 'objects' parameter, so the baseline is 3. The description adds no additional meaning about what happens when 'objects' is omitted (presumably all objects) or how names are matched.

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 (Find) and a specific target (sudden speed changes and loop seams / hitches in animation curves), even defining the jargon 'hitches'. An agent can tell this is a diagnostic inspection tool, though it never explicitly contrasts itself with the sibling 'animate' or 'animate_preset' with which it shares a domain.

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 never says when to run this check, in what workflow stage (e.g., after animate/animate_preset, before export), or what alternatives exist. Usage is only weakly implied by the word 'animation curves', so the agent must infer the trigger condition.

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 surfaces closer than tolerance count as touching, that embedded parts are included, and that results include gap distances plus nearest assembly part. The caveat 'Touching is not proof of the right mount' adds genuine interpretive guidance. It never states the tool is read-only/non-destructive, which is the main 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 front-loaded: the three reporting categories lead, and the two caveats about bounding boxes and false-mount confidence follow. Every sentence earns its place; only the run-on opening clause costs it a point.

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

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

For an analysis tool with no output schema and no annotations, the description needs to convey what comes back and roughly does: contact pairs, detached groups with gaps and nearest part, and loose-ended parts. What is missing is the output shape and confirmation that nothing is modified, but the coverage is otherwise solid.

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

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

Schema description coverage is 100%, so objects, tolerance, and check_ends are already fully documented (including the default of every visible part and the loose-end scope). The description adds no parameter-level detail beyond the schema, so baseline 3 applies.

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

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

States a specific analysis: which parts truly touch, which parts/groups are detached from the main assembly with gap and nearest partner, and elongated parts with loose ends. An agent knows exactly what it returns. However, it does not differentiate itself from the close sibling inspect_connections, leaving the choice between the two 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?

Implies a use case with 'Bounding-box checks miss these in dense models' and 'Touching is not proof of the right mount', which signals when the deep check is worth running. But there is no explicit when-to-use, no exclusions, and no routing against the similar inspect_connections sibling.

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 usefully disclose that restore replaces the current scene's objects with the snapshot and that the user's .blend file is untouched — an important non-destructive guarantee. But it is silent on the destroy/mutation semantics of delete, whether snapshots persist across sessions, and idempotency, leaving notable gaps for a 4-action 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?

A single front-loaded sentence with a useful parenthetical clarification; no filler or redundancy. It is efficient, though the brevity is partly why the other actions go unexplained.

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 stateful mutation tool with no annotations, no output schema and 0% parameter coverage, the description covers the destructive/rollback concept and the .blend safety guarantee but leaves the list and delete actions, the name parameter, and persistence behavior unexplained. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It implies the save and restore actions and mentions 'roll back' but never explains the 'name' parameter, nor what list and delete do or how they interact with name. Two of the four enum values are entirely undocumented anywhere.

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

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

The description states a specific verb+resource (snapshot the scene / roll back) and frames it around a clear scenario ('before risky edits'), which is distinguishable from siblings like clear_scene or get_scene_info. It stops short of explicitly naming alternative tools or how it relates to them, but the core purpose is unambiguous.

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

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

It gives a clear when-to-use for the save/restore workflow ('before risky edits... roll back if they go wrong'), which is helpful implied usage. However, the schema's four actions (save, restore, list, delete) are never differentiated in the description, so an agent gets no guidance on when to pick list or delete versus save/restore.

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 the concrete mutations performed (merging, deleting loose/degenerate geometry, recalculating normals), which tells the agent this is a destructive write. However, it never states irreversibility, whether it acts on the whole scene or a selection when 'objects' is null, or that merges can collapse unintended geometry.

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

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

A single tight sentence that front-loads the primary operation (merging verts) and lists the rest without filler. Efficient and scannable, though a comma-separated list rather than structured prose.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, the description covers the core intent but omits scope/default behavior (what happens when objects is null), the shading option, and any note on reversibility. Adequate but leaving the agent to guess on several call-affecting 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 coverage is only 17% (only 'objects' is documented), so the description must compensate, and it partially does: 'merge verts' maps to merge_distance, 'remove loose geometry' to remove_loose, 'degenerate faces' to dissolve_degenerate, and 'normals' to recalc_normals. It says nothing about the 'shading' enum or the meaning/threshold of merge_distance, leaving real gaps.

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

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

The description names a specific operation set on a specific resource: merging duplicate verts, removing loose geometry/degenerate faces, and unifying normals. An agent immediately understands this is a mesh-repair tool. It does not, however, distinguish itself from the close sibling edit_mesh, which likely also mutates mesh topology.

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

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

There is no guidance on when to run this versus edit_mesh, review_model, or analyze_quality, nor any stated prerequisite (e.g. selection state or that objects must be pre-selected). Usage must be inferred purely from the operation names.

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 the destructive scope ('delete every object') plus a safety practice (confirm with the user). It omits whether the action is reversible/undoable and does not reconcile 'every object' with the keep_camera/keep_lights options, so the behavioral picture is incomplete.

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

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

Two short sentences, with the core destructive action front-loaded and the cautionary note second. Efficient and readable, though the second sentence is instructional rather than informational.

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

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

For a destructive, no-annotation tool with two undocumented parameters and no output schema, the description covers the most important risk (irreversible-looking bulk deletion + user confirmation) but leaves gaps around undo behavior and the keep_camera/keep_lights options.

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 mentions keep_camera or keep_lights. With two undocumented parameters and no compensating text, an agent cannot learn from prose that it can preserve the camera or lights, so the description fails to fill the schema gap.

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

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

States a specific verb and resource: deleting all scene objects, with the clarifying parenthetical '(start fresh)'. It is clearly distinct from siblings like cleanup_mesh or organize_objects, though it doesn't explicitly name a counterpart the way a 5 would.

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

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

The description gives one conditional instruction -- ask the user first if the scene contains their work -- which strongly implies the tool is a last-resort/recovery action. However, there is no explicit when-to-use-vs-alternatives guidance or statement of when this is appropriate versus a more selective cleanup tool.

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

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

With no annotations at all, the description carries the full burden and does well: it discloses the return payload (IoU, aspect difference, per-height corrections with a concrete example and world z) and the overlay image color semantics (red = only in reference, blue = only in model). It also bounds the method's validity (cannot verify absolute dimensions, apertures, attachments, materials, AAA fidelity). It does not explicitly state that the operation is non-mutating/read-only, which is the main 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?

Front-loaded with the core comparison and its normalization constraint, then returns, then the fix-and-recompare workflow, then caveats. Every sentence carries unique information (scope, outputs, next action, validity limits) 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?

No output schema exists, so the description must describe returns, and it does so concretely (IoU, aspect difference, per-height corrections, overlay image). Combined with 100% parameter schema coverage and explicit limitations, an agent has everything needed to call it and interpret results.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds meaning by tying 'bands' to the returned per-height corrections ('at 70-80 % height...') and by telling the user to pair 'view' with the corresponding model view. That amplifies the schema beyond restatement, though it does not document each parameter exhaustively.

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's silhouette with a reference) and immediately narrows scope to 'proportions only (both normalised to their height)'. This is clearly distinguishable from siblings like review_model or analyze_quality, which serve different evaluation roles.

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 real workflow guidance: fix the listed bands via sibling edit_mesh (scale/soft_move on that z range) and compare again, plus prerequisites 'use corresponding reference/model views and separable backgrounds'. It also states what the tool cannot verify. It stops short of naming an explicit alternative tool for silhouette work, so it is strong but not exhaustive.

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

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

No annotations are provided, so the description carries the full burden. It does add one genuinely useful behavioral trait — the backdrop is auto-sized to the subject and placed at its lowest point — but says nothing about side effects, defaults, existing-scene impact, or what the call returns. For a creation tool with zero annotation coverage this is a large 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?

A single, front-loaded sentence with no filler — efficient and easy to scan. It is arguably too terse for a five-parameter tool, which keeps it short of a 5.

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

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

Given five parameters, no annotations, and no output schema, the definition should explain selection criteria and parameter behavior. It instead provides only a physical characterization of the resulting object, leaving usage and parameter semantics 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?

The description contributes no parameter information at all; it does not mention size, color, style, target, or material. With schema coverage at only 60%, two parameters (size, color) are undocumented in both places, so the description fails to compensate for the gap.

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

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

The description names a specific resource — a seamless studio backdrop or floor — and distinguishes it from primitive/geometry creators among the siblings. It lacks an explicit verb (reads as a noun phrase), so the action is implied rather than stated, but an agent can still tell what gets created.

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

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

There is no guidance on when to reach for this tool versus create_primitive, create_extrusion, or setup_lighting, and no prerequisites or exclusions are given. The only implicit cue is that it makes a backdrop/floor, which is not real usage 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 full burden. It adds genuinely useful behavioral context beyond the schema: origin is at the bottom centre and it returns top_z for stacking. However, it omits side-effect behavior (whether it adds the object to the scene, material defaults, or scene prerequisites) that an agent would want for a creation tool.

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

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

Two dense, front-loaded sentences that waste no words; the geometry concept leads and the origin/return note follows. Slightly terse for the tool's complexity, but every clause earns its place.

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

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

For a 13-parameter creation tool with no annotations, no output schema, and only 62% schema coverage, the description is thin. It covers purpose, geometry, and origin/return, but leaves usage selection and mutation/side-effect behavior unspecified, so an agent still has gaps to fill.

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 62%, and the description compensates meaningfully by explaining the geometry concepts behind the loosely documented params: bulging sides (bulge), crowned faces (crown), rounded-rectangle plan (corner), seam piping (piping), and optional buttons (tufted). It adds visual semantics the bare param names lack, though it stops short of units or value ranges.

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 what is produced (upholstered soft goods like a real cushion) and lists distinguishing geometric features (rounded-rectangle plan, bulging sides, crowned faces, seam piping, buttons). This lets an agent recognize it as a specialized cushion builder rather than a generic primitive, though it never explicitly contrasts itself with siblings like create_primitive or create_loft.

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 is given: nothing tells the agent when to reach for create_cushion versus create_primitive, create_loft, or create_extrusion, nor any preconditions. Usage must be inferred entirely from the geometry description.

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

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

No annotations are provided, so the description carries the full burden. It discloses useful behavioral traits about output quality and validation: 'clean quad sides', 'well-formed surface (even triangles, real quarter-round rims)', and that holes are checked. However, it omits other important behavioral context such as whether it creates a new object, modifies the scene, or has permission requirements.

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

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

The description is front-loaded with the core purpose and then branches into examples, plane advice, and shape-handling notes. It is reasonably efficient, though the list of example parts and the mid-sentence parenthetical are slightly dense; every sentence still earns its place.

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

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

Given 24 parameters, no output schema, and no annotations, the description covers the essential concept, key behaviors, and the main constraint (holes inside outline). It does not explain the full set of advanced options or the tool's return value, but the schema handles most parameter details and the core usage is clear.

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 79%, so the schema already documents most parameters. The description adds only minor semantic value beyond the schema, such as reinforcing that 'front elevation = XZ' (already in the schema) and noting that holes are validated, but it does not clarify the many other parameters (bevel, crown, subdivision, etc.).

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

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

States a specific verb and resource ('Extrude a 2D outline into a solid') and immediately differentiates from other modeling approaches by scoping it to silhouette-defined parts with concrete examples. The phrase 'give the shape here instead of adding a big Bevel or pushing vertices afterwards' further distinguishes it from alternative workflows.

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 usage context ('for anything defined by a silhouette') and a list of example parts, and advises against a common alternative (post-hoc Bevel). However, it does not explicitly name when to choose this over sibling tools like create_sweep or create_loft, nor does it state 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 full behavioral burden but only describes the geometry produced. It never states that a new object is added to the scene, whether an existing object is replaced, permission/collection effects, or failure modes. The worked example helps but does not substitute for behavioral disclosure.

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

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

The core definition is front-loaded in the first clause, followed by use cases and a compact worked example. It is appropriately sized for a creation tool with no wasted preamble.

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

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

For a complex 19-parameter creation tool with no annotations and no output schema, the description conveys the core concept and a usable example but omits behavioral context (object creation semantics, interaction with location/origin). It is adequate but has clear gaps an agent would need to infer.

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 74%, so most parameters are already documented, and the description's example (profile, cap=false, thickness) mostly illustrates values the schema already explains. It adds marginal tie-together value by showing a coherent vessel configuration but introduces no new semantics for the 19 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 description states a specific geometric verb+resource ('surface of revolution around the local Z axis') and enumerates concrete products (bottles, vases, columns), so an agent understands exactly what it builds. It does not explicitly distinguish itself from creation siblings like create_sweep, create_loft, or create_pipe, so it falls short of the 'differentiates from siblings' bar.

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

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

The phrase 'the best tool for anything round' plus a long list of example objects gives clear context for when to reach for this tool. It does not name a when-not condition or an alternative sibling for near-miss shapes (e.g. tubes/revolved pipes), so it misses the top tier.

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 says nothing about whether a new object is created, how the result interacts with existing scene geometry, permissions, or any side effects; the behavioral detail lives entirely in the schema. For a construction tool with zero annotation coverage this is a notable 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?

A single front-loaded sentence leads with the core action and then lists applications; it is dense but earns its words. Slightly long tail of examples but 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?

Given 18 parameters, no output schema, and no annotations, the description covers purpose and example forms but omits usage routing against the many sibling geometry tools and any behavioral notes. The rich schema compensates for parameter detail, but the description leaves sibling disambiguation 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 description coverage is 83%, above the 80% threshold, so the schema already documents nearly all 18 parameters (caps, bevel, smoothing, correspondence, etc.) in detail. The description adds no parameter-level meaning beyond what the schema supplies, making the baseline 3 appropriate.

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

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

States a specific action (skin a smooth surface) plus the method (through cross-sections) and enriches it with concrete form examples (fuel tanks, seats, hulls, fuselages). An agent can tell what it builds, though it never names the sibling modeling tools (create_sweep, create_extrusion, create_lathe) it must be distinguished from.

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 clause 'for forms whose section changes along their length' implies a usage condition and the object list gives contextual cues. However, there is no explicit when-to-use vs. when-not guidance and no routing to alternatives like create_sweep or create_extrusion, which overlap heavily with this tool.

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

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

With no annotations, the description carries the full burden. It does disclose a genuine behavioral fact beyond the schema: the result is one fused continuous body rather than butted cylinders. It says nothing about scene mutation, required context, or interaction with wall/caps, so the coverage is partial.

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

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

Two tightly packed sentences, front-loaded with the core concept and followed by concrete use cases; no filler. The prose style is evocative but each clause carries information.

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

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

For a 13-parameter tool with no annotations and no output schema, the description explains the concept and use cases but not units, defaults semantics, or the distinction from the other surface-creation siblings. Adequate as a conceptual blurb, thin as an invocation aid.

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 77%, so the schema already documents most parameters (path, radius, wall, bend_radius, section_scale all have good descriptions). The description only echoes 'radius changes along a curved path', adding no syntax or format detail beyond what the schema provides — the baseline of 3 applies.

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

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

Names a specific geometry (a single continuous tube with varying radius along a curved path) and immediately distinguishes it from a union of primitives via 'No separate cylinders butted together'. However it never states the create action explicitly nor names the close siblings (create_sweep, create_loft, create_extrusion) it must be told apart from.

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 examples (exhaust header, reducer, muffler, horns, bottle necks, hoses with sleeves, branches) imply when the tool is appropriate, so usage is inferable. But there is no explicit when-to-use statement and no routing against the similar creation siblings.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses a non-obvious trait (mesh data with scale held at 1 so bevels stay even) and the return value (world bounding box), but does not cover selection state, creation side effects, or permissions, leaving meaningful behavioral gaps.

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

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

Two tight sentences, zero filler, with the key trait (TRUE size / scale 1) and the return value front-loaded before any elaboration. Every clause earns its place.

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

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

For a 19-param, no-annotation, no-output-schema tool, the description covers the return value (compensating for the missing output schema) and the scale behavior, but omits routing to the other creation tools and any side-effect/permission context. Complete enough to call, incomplete as guidance.

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 95%, so the schema already documents all 19 parameters in detail. The description adds essentially no parameter syntax beyond the passing mention of bevels, so the baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ("Create a primitive") and adds a distinguishing trait (built at TRUE size, scale stays 1). It does not differentiate from the numerous sibling creation tools (create_lathe, create_extrusion, create_sweep, create_loft, create_pipe), so an agent cannot tell from the text alone when a primitive beats a lathe or extrusion.

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: "so you can place the next part precisely" hints at an iterative placement workflow, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many create_* siblings. Adequate but gapped.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: it does not say whether a new object is created, whether default caps produce watertight geometry, or that bevel/subdivision modifiers may be attached. The examples hint at capability, not 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?

It is a single front-loaded sentence that leads with the core action and then supplies examples; nothing is padded with filler. The example list is long but earns most of its space by illustrating the tool's range.

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 17-parameter creation tool with no annotations and no output schema, the description is too thin: it never clarifies defaults (caps=true, smooth=true, resolution=12) or how the many parameters relate. An agent must fall back entirely on the schema to call it correctly.

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

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

Schema description coverage is 71%, so the schema itself documents most parameters and the baseline is 3. The description adds only incidental hints ("picture frames (closed + rect)" points at closed/profile, "horns (taper)" points at taper) and explains nothing about the other parameters or how they interact.

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 ("sweep") and resource ("a profile along a 3D path") and reinforces it with concrete object examples. However, it never distinguishes this tool from close siblings like create_pipe, create_loft, or create_extrusion, so an agent cannot tell from the description alone which of these mutually similar path/profile tools to pick.

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 example list (handles, pipes, cables, springs, horns), which signals appropriate scenarios, but there is no explicit when-to-use, no when-not, and no named alternative. The agent is left to infer that create_pipe/create_loft are the competing choices.

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 behavioral burden, yet it only states the output type. It does not disclose whether this operation is destructive, whether it requires an active scene/collection, what the returned object handle is, or how many objects it adds for multi-line text. 'Beveled edges' hints at geometry but no default or range is given.

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

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

One short sentence, front-loaded and free of filler. It is efficient but perhaps too terse for a 13-parameter constructor, trading completeness for brevity.

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 tool with 54% schema coverage, no annotations, and no output schema, the description is far too thin. It omits critical setup context (font availability, units, parent/collection semantics, material handling) that an agent needs to call this correctly.

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

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

Schema description coverage is 54%, leaving 6 of 13 parameters (name, text, align, parent, collection, bevel_depth) with no semantic note in either the schema or the description. The description adds nothing beyond what the schema already documents for the other fields.

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

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

The description names a specific verb/resource pair ('3D text') and discloses the key transformation ('converted to a mesh') and a visual trait ('beveled edges'), which distinguishes it from the other create_* tools that build geometry procedurally. It stops short of naming an alternative but the resource is unambiguous.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g. needing a font file path, material presets, or an active scene), and no routing to alternative tools such as create_primitive or import_model_file. An agent cannot infer from the description when this is the right choice versus creating the text elsewhere.

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 the cross-tool side effect (suppressing flags in check_contacts and the delivery gate), which is real behavioral context. However, it doesn't say whether declarations persist across sessions, whether they are reversible, or what the tool returns, leaving meaningful gaps for a write-style 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?

A single front-loaded sentence that states the action and its downstream consequence with no filler. Nothing could be removed without losing information.

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

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

For a 3-parameter tool with fully documented schema and no output schema, the description covers purpose and effect adequately. It falls short only on persistence/reversibility and expected return behavior, which an agent might reasonably want before calling it repeatedly.

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

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

Schema description coverage is 100%, including a nuanced explanation of ends_only ('exhaust outlet, a cable whose plug is hidden'), so the schema does the heavy lifting. The description adds no parameter detail, making the baseline 3 correct.

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

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

States a specific verb (record) and resource (intentional separation), and immediately names its downstream consumers (check_contacts, the delivery gate), which distinguishes it from those siblings. The phrase 'the delivery gate' is undefined jargon, but the core intent — marking objects as deliberately disconnected — is inferable.

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 trigger: use this when a separation is intentional so that check_contacts and the delivery gate don't flag it. It implicitly excludes unintentional separations but never states that explicitly, nor does it mention when re-declaring or clearing a declaration is needed.

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

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

No annotations are provided, so the description carries the full burden. It discloses one behavioral trait (the original becomes the first item) but says nothing about scene mutation, reversibility, whether existing objects are affected, or the return value. For a 17-parameter generation tool this is a significant 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?

Two sentences, front-loaded with the core action before the examples, with essentially no filler. The trailing example list is a little loose but earns its place as disambiguation.

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

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

For a complex 17-parameter tool with no annotations and no output schema, the description is far too thin. It fails to connect the five pattern modes to their governing parameters or describe what calling it changes in the scene, leaving most of the tool's behavior 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 description coverage is only 24% across 17 parameters, so the description must compensate, yet it explains no parameter at all. The examples loosely hint at radial and grid modes but give no mapping to axis, count, offset, spacing, positions, radius, center, mirror_axes, or name_prefix.

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

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

The description gives a specific verb+resource ('Repeat an object in a pattern') and adds a concrete behavioral fact ('the original becomes the first item'). The real-world examples (legs, spokes, chairs, shelves, bolts, tiles, fence posts) make the intent immediately graspable. It does not explicitly distinguish itself from the sibling 'scatter', which also places many copies, so it stops short of a 5.

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

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

Usage is only implied through the illustrative examples, which suggest radial (spokes, chairs), grid (tiles, shelves), and linear cases. There is no explicit statement of when to choose this over siblings like scatter or the create_* tools, and no prerequisites or exclusions are given.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses only 'world-space selections' and 'no edit-mode needed'; it says nothing about whether operations mutate/destroy existing geometry, permission needs, or reversibility. For a 26-operation mesh mutation tool this is a significant 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?

Two sentences, front-loaded with the capability statement before the examples. The examples are dense but each maps to a real operation, so little is wasted; it is appropriately sized for what it does say.

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 30-parameter, 26-operation tool with no annotations and no output schema, the description is far too thin. It leaves most parameters and the destructive/reversibility profile unexplained, relying on the operation enum in the schema to carry the load.

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 only 27% across 30 parameters, so the description is expected to compensate heavily. It names a handful of operation values (extrude, inset, bevel, soft_move, loop_cuts, bisect, clear_outer) but never explains the many undocumented knobs (depth, width, thickness, value, cut counts, profile, falloff, plane_point/normal, etc.).

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 ('Edit mesh geometry') and adds the world-space/no-edit-mode qualifier, which is a distinguishing property. The example list clarifies the kind of operations available. However, it never names or contrasts with close siblings like cleanup_mesh or transform_object, so the agent gets little help disambiguating.

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 'Typical:' examples imply when certain operations apply (extrude for necks, bevel for rims, loop_cuts before deforming), which is useful implied usage. But there is no explicit when-to-use guidance, no exclusions, and no routing to alternative tools for object-level transforms or mesh cleanup.

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 the key tradeoff (dedicated tools 'carry the quality defaults', implying this one does not) but says nothing about the code running with full scene access, mutability, irreversibility, or error behavior. Useful but incomplete for an arbitrary-code-execution tool.

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

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

Two tightly packed sentences: purpose and scope first, then the preference rule. Zero filler, front-loaded, and the parenthetical examples earn their space.

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

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

For a single-parameter tool with no output schema and a schema that already describes the execution environment and return mechanics, the description covers purpose and selection adequately. The remaining gap is execution risk/side-effect disclosure, which is minor but real for an arbitrary-code tool.

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

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

Schema description coverage is 100%, and the schema already documents the environment and output mechanics (bpy, bmesh, roxy, print/result). The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

The description frames the tool as an 'escape hatch' for 'anything the dedicated tools don't cover' and names concrete use cases (geometry nodes, drivers, particles, bmesh, animation). It clearly distinguishes this from the many dedicated siblings, though the literal verb+resource (run Python) is carried by the name and schema rather than the description text.

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 an explicit when-to-use ('anything the dedicated tools don't cover') and an explicit when-not ('Prefer the dedicated tools'), naming the reason (quality defaults). This is exactly the routing guidance an agent needs and leaves no ambiguity about choosing this over a dedicated tool.

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

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

With no annotations, the description carries the full behavioral burden, yet it says nothing about whether an existing file is overwritten, whether export mutates or reads the scene, whether permissions are needed, or what a successful export returns. For a file-writing operation this is a notable 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?

A single efficient sentence, front-loaded with the action and scope, with no filler. It is well-structured, though it could have used one more sentence for the missing behavioral and parameter context.

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

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

For a 4-parameter file-export tool with no annotations and no output schema, the description omits overwrite semantics, export scope (whole scene vs. selected objects), and any note on apply_modifiers. An agent can call it, but cannot predict its 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 coverage is 75%, and the description adds zero parameter-level meaning beyond it — the format-target mapping and extension-picks-format behavior are already in the schema. Critically, apply_modifiers has no schema description at all and the description does not compensate for it.

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

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

States a specific verb (Export) and resource (models) and lists target destinations (game engines, web, AR, 3D printing), which is clearer than a bare tautology. However it does not distinguish itself from the sibling export_skeletal, which an agent must choose between, 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?

The description names output use cases but gives no when-to-use/when-not guidance and never mentions the alternative export_skeletal or import_model_file. An agent gets no routing logic for picking between the export 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?

With no annotations, the description carries the full burden, and it does disclose substantial behavior: output filename conventions, centimetre scale, leaf-bone stripping, root bone naming, and per-frame easing baking. It does not state side effects such as whether files are overwritten or whether a disk path must exist, so it falls short of full transparency.

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

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

A single front-loaded sentence uses a colon and semicolons to pack purpose, output artifacts, and export conventions with no filler. Every clause adds information an agent can act on.

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

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

For a five-parameter tool with no annotations and no output schema, the description covers the export result well but omits the semantics of fps, armature, and export_dir and says nothing about failure modes or return values. Adequate but with clear gaps.

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

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

Schema description coverage is only 20% (just 'actions'), so the description must compensate across five parameters. It clarifies name and actions via the output naming pattern and mentions per-frame timing tied loosely to fps, but fps, armature, and export_dir carry no meaning in either the schema or 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?

It states a specific verb (UE5 export) and a specific resource (a rigged prop), and enumerates the exact artifacts produced (SK_<name>.fbx skeletal mesh plus per-clip A_<name>_<action>.fbx). The 'skeletal/rigged' framing implicitly separates it from the sibling export_model, so an agent can route without opening a schema.

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

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

The scope (UE5, rigged prop) implies when the tool applies, but there is no explicit when-to-use/when-not statement and no named alternative. The agent must infer that export_model is the non-rigged counterpart.

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 scope of the knowledge base (what topics return content), but does not state that the operation is a read-only lookup, nor describe output shape or size. For a low-risk documentation fetch this partial disclosure is acceptable but not strong.

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?

Compact, front-loaded with the core purpose ('Modeling know-how on demand'), followed by a single dense list where each item corresponds to available content. No filler sentences, though the comma-separated wall lacks grouping or hierarchy.

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, no-annotation, no-output-schema tool the description covers what content is available, which is the main need. It omits when to invoke it and the index-discovery affordance documented in the schema, leaving a modest gap in operational completeness.

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 already 100%, so the baseline is 3, but the description goes beyond the terse schema entry by effectively enumerating the valid topic names (workflow, dimensions, japan, game_assets, recipes, etc.), which meaningfully constrains and guides the single parameter. It stops short of mapping each topic to its exact enum string.

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 frames the tool as on-demand modeling know-how and enumerates the domains it covers (hard_surface, organic, detailing, materials, troubleshooting, etc.), so an agent can tell it retrieves reference guidance rather than performing a modeling action. It is distinguishable from action siblings like edit_mesh or create_primitive, though it never states the verb 'get/retrieve a guide' explicitly.

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

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

There is no explicit when-to-use guidance: nothing says to consult this before authoring geometry, nor when it should be skipped in favor of execute_python or the reference-comparison siblings. The topic list implies what content exists but not the conditions that should trigger a call. The schema's 'call with index to list them' hint is not echoed in the description.

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

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

No annotations are provided, so the description carries the full burden. It discloses the read-only nature implicitly (an 'overview' query) and lists what fields are returned, which is useful. However, it does not state pagination behavior despite a 'limit' parameter, nor whether results are truncated, nor whether it is safe/non-mutating explicitly. The disclosure of returned fields is genuinely helpful but incomplete for an unannotated tool.

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

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

Two clauses, front-loaded with the return payload then the usage condition. No wasted words and the most important information (what you get) comes first.

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, no annotations, and 67% param coverage, so the description must do more. It handles the return-shape burden well by enumerating fields, but it omits pagination/limit semantics and any mention of read-only safety, which for a no-annotation tool are meaningful gaps.

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

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

Schema description coverage is 67%: 'query' and 'collection' are documented in the schema, while 'limit' (default 60) has no description in either place. The description adds no parameter-level detail beyond what the schema already provides. Baseline 3 is appropriate given partially-complete schema coverage and no compensating 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 clear verb+resource: returns a 'scene overview' enumerating objects, locations, sizes, bboxes, modifiers, materials, camera/lights, and overall bounding box. It tells the agent exactly what data comes back, distinguishing it from inspection siblings like inspect_object. It does not explicitly differentiate itself from get_status or inspect_object by naming alternatives, but the enumeration is specific enough to be useful.

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 before editing an existing scene.' clearly gives the when-to-use condition and implicitly contrasts with tools that create scenes from scratch (create_primitive, import_model). It does not name a concrete alternative (e.g., inspect_object for a single object), but the temporal guidance is 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 present, so the description carries the full burden. It usefully discloses the exact contents of the response, and the read-only nature is implied by "connection status", but there is no statement about side effects, permissions, or failure modes if Blender is not connected.

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

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

Two short sentences, with the payload contents front-loaded and the usage instruction second. No filler, 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, the description must describe the return payload, and it does so by enumerating the fields returned. It is complete enough to decide to call it, though it does not describe the format or failure behavior when no Blender connection exists.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. No parameter explanation is needed or missing.

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

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

States a specific resource (Blender connection status) and enumerates the returned facets: versions, file, engine, scratch folder, and configured asset libraries. This distinguishes it fairly well from the scene-level sibling get_scene_info, though the differentiation is implicit rather than stated.

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

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

"Call it once at the start" gives explicit timing and invocation count, which is genuinely useful guidance for a setup/orientation tool. It stops short of naming alternatives (e.g. get_scene_info) or stating when not to call it.

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

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

No annotations exist, so the description carries the full burden, and it discloses real post-processing behavior per mode: models are cleaned, real-sized, grounded and credited; textures become box-projected PBR materials; HDRIs drive world lighting. It stops short of safety/mutation details - it never says what 'replace' or 'preview' do to existing scene objects, nor any download/network constraints.

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

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

Three dense sentences, front-loaded with the core action and then a terse per-type breakdown. No filler; every clause conveys distinct behavior.

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

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

For a 20-parameter mutation tool with no annotations and no output schema, the mode coverage is good but the parameter interplay and the effect on the existing scene are not explained. It is adequate as a conceptual overview but incomplete as invocation guidance.

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

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

With 20 parameters and only 55% schema coverage, the description adds conceptual context that helps interpret the type-specific clusters (strength/background/hdri_rotation for HDRIs, apply_to/faces for textures). It still names no parameters directly and leaves many of the 20 (name, preview, replace, place_on, rotation, max_faces, etc.) undocumented in both schema and prose.

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 ('Download an asset ... and bring it in scene-ready') and names the sibling it follows from ('found with search_assets'). It also breaks the outcome down by asset type (models/textures/HDRIs), so an agent knows exactly what this tool produces without opening the schema.

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

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

The prerequisite workflow is embedded explicitly: find with search_assets, then import here. However, no exclusions or alternatives are given for the nearby sibling import_model_file, so the agent must infer the boundary between importing an online asset and a local model file.

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 disclosure burden for a mutating import. It gestures at 'the same clean-up as library assets' but never says what that clean-up does, whether an existing object is overwritten, or how 'replace'/'preview' alter scene state — a significant gap for a write operation.

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

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

A single front-loaded sentence with no filler, which is structurally fine, but its brevity reflects under-specification rather than economy — one clause is expected to carry a 12-parameter mutating 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?

Given 12 parameters, no annotations, no output schema, and 25% schema coverage, the description is far too thin. An agent cannot confidently invoke this without knowing how the many optional placement/cleanup arguments interact with existing geometry.

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

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

Schema description coverage is only 25% across 12 parameters, so the description must compensate and does not. It adds no meaning beyond the path argument (which the schema already documents) and leaves join, fit_to, place_on, rotation, replace, preview, and target_size unexplained in either place.

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 ('import a model file from disk') and implicitly contrasts with the sibling import_asset by scoping to disk files rather than library assets. It is not a tautology, but it never names the alternative tool to make the distinction 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?

No when-to-use guidance, no prerequisites, and no named alternative. With both import_asset and import_model_file among siblings, the agent must guess which one applies to a given source, and the description offers no routing rule.

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 reasonably: it discloses that tolerances must be justified, that gaps/misplaced endpoints are reported, and enumerates five capabilities it lacks to prevent misuse. It omits whether the operation is read-only or touches scene state, but 'inspect/measure' strongly implies non-mutating.

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?

Mostly dense but front-loaded, with the negative list earning its space by scoping expectations. The trailing 'Inspect close-ups too.' is abrupt and vague, slightly weakening structure.

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

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

For a single-array-parameter inspection tool with no output schema, the description supplies the needed scope, tolerance guidance, and explicit exclusions. It is complete enough to call correctly, though return/report format is only implied.

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

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

Schema coverage is 100%, so the schema already documents the connections array in depth, setting a baseline of 3. The description adds real value on top by stating that tolerances must be justified from the design/scale, which is semantic guidance not present in the schema.

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

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

States a specific verb (measure/inspect) and resource (explicit attachment points against evaluated world-space geometry), and sharply distinguishes itself from a weaker technique (bounding-box checks) and from siblings like check_contacts by naming what it does not cover.

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?

Offers clear context on when this applies (attachment points vs evaluated geometry) and a strong negative list (does not discover partners, certify fidelity, compute penetration, sweep collisions, or simulate). It does not, however, explicitly name an alternative tool like check_contacts to route the agent.

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 helpfully enumerates the returned facets (compensating for the missing output schema), implying a read-only introspection call, but it never states that it is non-mutating, what happens if the name is not found, or any permission/error 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?

A single front-loaded sentence followed by a dense parenthetical list of returned fields; nothing is padded. Slightly list-heavy but every item earns its place by defining scope of the inspection.

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

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

For a simple one-parameter read tool with no output schema, the enumeration of returned content is the key value and it is present. However, it omits usage guidance versus siblings and parameter format, leaving the definition only minimally adequate.

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?

One parameter ('name') exists with 0% schema description coverage, so the description must compensate. It only vaguely implies the parameter refers to the target object, without clarifying expected format (exact name, path, uniqueness, or matching semantics).

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

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

Clear specific verb ('inspect') and resource ('one object'), and it enumerates exactly what facets are reported (transform, bbox, topology, shading, modifiers, materials, UVs, children). This implicitly scopes it to a single object versus a scene-wide tool like get_scene_info, but no sibling is named explicitly.

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

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

The description only implies it is for inspecting; it states no when-to-use condition, no prerequisites (e.g., object must exist), and names no alternative such as get_scene_info for scene-level queries. An agent must infer when to pick this over its many siblings.

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

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

No annotations are provided, so the description carries the full burden, but it is a zero-parameter read-only enumeration with low behavioral risk. It does disclose the useful trait that each preset comes with a one-line description, which compensates in part for the absent output schema, yet it says nothing about ordering, pagination, or whether the returned names are usable by apply_material.

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

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

A single short sentence with no filler, and the key entity (material presets) is front-loaded. Nothing could be trimmed without losing information.

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

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

For a trivial zero-param list tool this is nearly sufficient, and the description does hint at the returned content. However, with no annotations and no output schema, it leaves the agent guessing about return volume and how the listed preset names feed into downstream tools like apply_material.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify beyond what the empty schema already conveys.

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 concrete verb+resource pair ('list ... material presets') and even previews the return shape ('one-line description'). It is distinguishable from siblings like apply_material or search_assets, but it does not explicitly contrast itself with any of them.

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

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

There is no statement of when to call this versus alternatives such as search_assets or apply_material, and no prerequisites or exclusions are given. The word 'All' weakly implies an unfiltered enumeration, but nothing routes the agent.

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 meaningful behavior: output is a single contact-sheet image, orthographic views encode their frame width in metres (a scale cue), and frames=[...] switches to a time-series strip. It does not say whether the operation is purely read-only or mention side effects, but for a view/render tool this is near-complete.

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 compact sentences, front-loaded with what the tool does, then the recommended cadence, then the frames variant. Every sentence earns its place with no redundancy.

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

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

There is no output schema, but the description explains the returned artifact (a contact-sheet image) and the animation variant, and all parameters are schema-documented. For a seven-parameter rendering tool this is sufficient, leaving only minor gaps around side effects and sibling selection.

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

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

Schema description coverage is 100%, so the schema already documents all seven parameters, establishing a baseline of 3. The description adds some value by explaining the frames parameter's time-strip behavior and the metre framing of orthographic views, but does not elaborate on size, target, isolate, or shading beyond the schema.

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

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

The name 'look' is vague on its own, but the description states a concrete verb+resource: it renders several angles into one contact-sheet image, and notes the animation-strip mode. It is clear what the tool produces, though it never names the siblings it differs from (viewport_screenshot, render_image, review_model), so an agent must infer the distinction.

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

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

It gives explicit call cadence ('call it after every few modeling steps') and the reason ('catch wrong proportions, gaps and intersections'), which is strong when-to-use guidance. However, it offers no when-not guidance or alternative tools for the same visual-feedback need.

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 runtime ('1-4 minutes'), the exact baking scope (all Blender-only effects into BaseColor/Normal(DirectX)/ORM with channel ordering), transparent-part handling, and collision generation. It omits whether the operation is destructive to the source mesh, how it behaves when an export directory already exists, and whether it modifies the current scene, which keeps it from a 5.

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

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

The outcome is front-loaded in a single dense sentence, followed by two short operational notes (runtime, review_model follow-up). Every clause carries real information, though the first sentence is long enough that an agent has to parse it carefully.

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, zero-required tool with no output schema, the description covers the produced artifacts, texture naming, and runtime well, so an agent knows what to expect. Remaining gaps are minor: no guidance on default naming when 'name' is null and no statement about overwriting behavior in export_dir.

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 high (82%), so the schema already documents most parameters including lods, mode, collision, texel_density, and name conventions. The description adds texture-channel and naming context but no syntax or defaulting guidance for the undocumented parameters (max_texture, small_part_ratio, export_dir fallback), so baseline 3 is appropriate.

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

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

The description opens with a specific verb+resource pair ('Turn a finished Roxy model into a UE5-ready game asset') and then enumerates exactly what the output contains: game mesh, UVs, baked maps with channel layout, collision, and FBX. It is clearly distinguishable from siblings like export_model, uv_unwrap, or review_model because it is the end-to-end packaging step.

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

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

It states the precondition ('a finished Roxy model') and the follow-up action ('Run review_model(objects=[...], purpose="game") afterwards'), and even advises when LODs are unnecessary ('UE5 Nanite usually makes these unnecessary'). It does not explicitly rule out alternatives (e.g. when to use export_model instead), 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, the description carries the full behavioral burden. It does disclose one genuinely non-obvious trait — that applying a boolean deletes its hidden cutter if unused — which is valuable, but it says nothing about the destructive nature of remove, permissions, reversibility, or what update changes.

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

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

Two tight sentences with zero waste: the capability is front-loaded and the non-obvious boolean side effect is called out immediately after. Well sized for 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?

No output schema exists, so the description must cover behavior and results, and it only partially does. For a five-parameter, six-action tool with no annotations, the omission of move/apply_all semantics and update behavior leaves meaningful gaps.

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

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

Schema description coverage is 60%, with name, index, and params documented in the schema itself. The description maps some verbs to the action enum (list/update/remove/apply) but adds no syntax or format detail beyond the schema and omits the move/apply_all actions and the meaning of index.

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 specific verbs (list/tweak/remove/apply) operating on the resource 'modifiers', so the agent knows it is a multi-action management tool rather than a creation tool like the sibling add_modifier. The description omits two enum actions (apply_all, move), so it does not fully enumerate what the tool does, but the core purpose is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives such as add_modifier, nor any indication of prerequisites or when each action is appropriate. The listed actions imply usage, but nothing tells the agent which one to pick or when not to use this tool.

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

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

With no annotations, the description carries the full burden and does well: reset discards only the checklist (not the model), state is stored in the Blender scene and saved with the .blend, delivery checks are preserved across recording, and explicit limits are stated ('No image-content analysis, evidence-truth verification or complete dependency tracking'). The clipped phrasing leaves a few invariants ambiguous, keeping it below 5.

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

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

Purpose is front-loaded in the first sentence, but the body is a dense run of fragments and multi-clause sentences ('Passing stages requires their comparisons; failed comparisons require recorded repairs and fresh model images before passing') that demand re-reading and intermix rules with limitations.

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

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

For a complex stateful tool with 18 optional params and no output schema, the description covers workflow order, invariants, invalidation rules, and explicit non-goals, which is nearly what an agent needs. It stops short of describing what each action returns (beyond 'report lists blockers'), leaving some call-outcome ambiguity.

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 61%, so the schema already documents most of the 18 parameters (features, findings, comparisons, on_error, evidence, etc.). The description only adds meaning for a few behaviors (reset scope, report/ready_for_delivery semantics) and gives no per-parameter syntax beyond what the enum and schema titles convey, so the baseline 3 applies.

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

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

The opening line names a specific artifact and scope: a 'Scene-persistent per-part completion checklist' with stage inspection and evidence recording. It is clearly a bookkeeping/state-machine tool, distinguishable in kind from siblings like review_model or analyze_quality, but it never explicitly names those alternatives to route the agent.

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?

Offers substantial when/how guidance: passing requires all earlier stages and no unresolved findings, rechecks invalidate later stages, changes to geometry/material/reference require invalidating the earliest affected stage first, and only one active plan per scene. It lacks explicit exclusions ('do not use this instead of X'), but the procedural context is strong.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose two useful traits ('group under an empty (moves as one unit)', 'select (highlights for the user)'), but omits any warning that delete is destructive, whether operations are undoable, or the fact that many params (angle, shading, collection, target) only apply to specific actions.

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 compact run-on list; every entry earns its place and the actions are front-loaded. The 'Housekeeping:' prefix adds little, and the run-on form makes the action-to-behavior mapping harder to scan than a structured list, but there is 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 7-parameter, 15-action umbrella tool with no annotations and no output schema, the description is a bare action inventory. It never maps params to actions, never flags destructive actions, and gives no return-value or side-effect context, leaving significant gaps for an agent to guess at.

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 57%: name, target, objects, and shading have schema descriptions, while action, angle, and collection have none. The action list in the description maps onto the enum and adds semantic context for group/select/shade, but it does not explain the action-to-parameter coupling an agent needs.

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 15 specific operations (rename, join, parent, shade, apply_transform, convert_to_mesh), so an agent knows exactly what the tool does. However it offers no differentiation from overlapping siblings such as transform_object, edit_mesh, or duplicate_pattern, and the 'Housekeeping' label is a mushy category rather than a scope statement.

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

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

No when-to-use guidance and no mention of alternatives, despite clear overlap with transform_object (apply_transform), edit_mesh (join), and duplicate_pattern (duplicate). Nothing tells the agent which of the enumerated actions belong here versus a sibling tool.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the placement mechanism (world bounding boxes) and the intended outcome (no floating cups or sunken legs), but is silent on failure behavior (missing target, unrenderable geometry), reversibility, or any side effects beyond the object itself.

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