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

Annotations only show readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so they do little to characterize behavior. The description confirms adding a camera but does not disclose side effects like object creation in the scene, active status changes, or what happens when location/rotation are omitted.

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

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

Three short sentences, no filler, and the core purpose is front-loaded. The lens/fov clarification and point_at tip are directly relevant and each sentence earns its place.

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

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

With nine parameters, no output schema, and no substantive behavioral or return-value information, the description is not complete enough for an agent to confidently handle edge cases. It supports a basic add-camera call, but many parameters and the tool's result format remain unexplained.

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 22%, so the description must compensate for the many undocumented parameters. It adds useful meaning for lens (units and examples) and fov_degrees (alternative to lens), but leaves location, rotation, collection, active, and name without meaningful elaboration, and point_at is only lightly reinforced.

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 'Add a camera', a clear verb+resource statement that leaves little doubt what the tool does. It does not explicitly distinguish itself from camera-related siblings like blender_set_active_camera or blender_look_at, but its wording and camera-specific parameters are distinct enough.

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 choose this tool over alternatives such as blender_set_active_camera, blender_look_at, or blender_add_light. The only usage hint is 'Usually also pass point_at so it is actually aimed at something', which advises on parameter usage rather than tool selection.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the description is not required to restate those. However, it adds no new behavioral context, such as side effects (e.g., creating a new object in the scene, affecting the active collection) or limitations. The description focuses on parameter values, not on what happens when the tool executes, leaving behavioral expectations to inference.

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

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

The description is two concise sentences, front-loaded with the core action 'Add a light' and immediately followed by practical parameter guidance. Every word earns its place; no filler or redundancy. This is exemplary conciseness for a tool with many parameters.

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 11 parameters and only 27% schema coverage, the description is far from complete. It does not explain how to specify position, orientation, or collection membership, nor does it mention the effect of the operation on the scene. There is no output schema to clarify return values, so the description bears the full burden of context, which it fails to meet.

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

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

With schema description coverage at only 27%, the description must compensate for undocumented parameters. It does provide meaningful semantics for 'energy' (typical values per type) and 'size' (softens shadows on AREA/POINT), which go beyond the schema's bare field names. However, it leaves most other parameters (name, location, rotation, collection, etc.) without any explanation, so the compensation is partial and not comprehensive.

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

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

The description clearly states the verb 'Add' and the resource 'light', which unambiguously identifies the tool's function. It distinguishes from siblings like blender_add_camera by naming the resource, though it does not explicitly contrast with alternatives. The typical energy ranges add useful specificity without diluting the core purpose.

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

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

The description provides no guidance on when to use this tool versus alternatives. It offers parameter tuning suggestions (energy values, size effect) but does not state the intended scenario, prerequisites, or cases where a different tool like blender_set_context or blender_add_camera would be more appropriate. This is a clear gap for a tool with 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?

Annotations already mark the operation not read-only and not destructive; the description builds on this by clarifying that the modifier remains live and tweakable unless the apply sibling is used. This adds practical behavioral context beyond the structured hints.

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 front-load the core action and add the key non-destructive distinction without wasted words. 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 moderate-complexity mutation with no output schema, the description plus schema gives an agent enough to select and call the tool: required object/type, optional flags/properties, and guidance on whether to apply. It does not describe return values, but the absence of an output schema is partially offset by clear purpose and sibling routing.

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 67%: type, flags, properties, and response_format are documented in the schema, while name and object lack descriptions. The tool description itself adds no parameter-level meaning, but the two required parameters are largely self-explanatory and the schema covers the rest.

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 ('Add a modifier to an object') and immediately distinguishes itself by labeling the operation non-destructive and naming blender_apply_modifier as the permanent counterpart. An agent can separate it from the apply-modifier sibling without opening the schema.

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

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

It gives clear usage context: adding is non-destructive, and the caller can either use blender_apply_modifier to flatten the result or leave it in place for a live, tweakable result. It names the alternative but does not explicitly enumerate when not to use this tool; the guidance is clear rather than fully prescriptive.

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

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

Annotations are all false/unspecific, so the description carries the behavioral burden. It discloses that the tool creates in the scene and returns a full description, and the example illustrates response-affecting options like shade_smooth. It does not clarify selection effects, naming defaults, or the exact shape of the returned description, but there is no contradiction.

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 main sentence plus a compact, relevant example. The core action and return behavior are front-loaded, and every phrase in the example earns its place by clarifying real usage.

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?

Adequate for a simple primitive-adding tool: the example and schema defaults cover the main call pattern. But with 10 optional parameters, no output schema, and no explicit return-shape description, an agent still has to infer how materials, collections, and response_format interact, so the description is not fully complete.

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

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

The example adds real meaning beyond the schema by showing how type, parameters, and shade_smooth combine for a torus, and it introduces primitive-specific parameter keys (major_radius, minor_radius, segments). With 60% schema coverage, this usefully compensates for schema gaps, although not every parameter is illustrated.

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

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

States a concrete action ('Add') and resource ('mesh primitive to the scene'), and adds that it returns a full description. It is not a tautology and is distinguishable from generic siblings, though it does not explicitly differentiate from blender_create_mesh.

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 action itself implies when to use it (when a mesh primitive is needed), and the torus example provides a concrete invocation pattern. However, it gives no explicit guidance about when not to use it or which sibling to prefer (e.g., blender_create_mesh for custom meshes).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description reinforces the safe read-only nature and adds specific behavioral scope: it enumerates exactly what is analyzed, including edge census, shell closure, signed volume, duplicate-vertex precision (1e-5), and modifier stack. This is useful context beyond the annotations.

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

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

The description is well front-loaded with a strong summary, followed by a compact list of statistics and a decision-oriented closing sentence. It is slightly dense but each clause carries meaning and nothing is redundant.

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

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

For a read-only analysis tool with no output schema, the description gives a thorough inventory of what the report covers and a stated use case. It does not mention units, failure behavior for non-mesh objects, or exact result structure, but the enumerated statistics and response_format parameter provide enough for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so both parameters are already documented in the input schema. The description adds the notion of 'one mesh' but does not materially expand on the object parameter or the response_format parameter beyond what the schema provides. 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 'Deep statistics for one mesh' and makes explicit it goes beyond face counts to include topology, volume, area, UV layers, vertex groups, and more. The verb 'analyze' plus a specific resource and clear scope make it plain what the tool does and why an agent would choose it.

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

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

It states a concrete decision use-case: 'Use it to decide between fixing a mesh and regenerating it.' This gives the agent context for when to invoke it, though it does not name alternative sibling tools like blender_measure, blender_validate, or blender_find_problems or explicitly say when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds what the report contains (frame range, actions, animated objects) but does not disclose return structure, formatting details, or whether it applies to the current scene/context, which is useful but not critical.

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

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

The description is a single, front-loaded sentence of about 12 words with no filler. Each phrase contributes distinct information: frame range, actions, and animated objects.

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 low-complexity, optional-parameter info tool with read-only annotations, the description covers the core output categories. It does not specify the exact JSON/markdown return shape, but the response_format parameter and the simplicity of the tool make this a minor gap rather than a blocking one.

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 only parameter, response_format, is fully documented in the schema with an enum and a description, giving 100% schema coverage. The tool description adds no parameter-specific meaning, 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 uses a specific verb ('Report') and names concrete resources: frame range, all actions, and animated objects. This clearly distinguishes it from siblings like blender_set_frame, blender_list_objects, and blender_insert_keyframe, which cover different aspects of animation and scene state.

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

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

The description implies when to use the tool—whenever animation state information is needed—but it gives no explicit context, exclusions, or alternatives. It does not say 'use this instead of X' or describe when another sibling would be more appropriate, so usage guidance is only implicit.

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

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

The description does not disclose behavioral details beyond what annotations already state. It doesn't mention side effects on the current scene, potential overwrites, or the effect of the 'names' parameter when omitted. With readOnlyHint=false and destructiveHint=false, some mutating behavior is implied, but the description adds no specific behavioral context.

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

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

The description is a single, well-structured sentence that leads with the action and resource, and succinctly states the purpose. No wasted words.

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

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

The description covers the core operation but leaves out important context such as how the append integrates with the current scene, what happens when 'names' is null (append all?), and whether the operation is additive or can conflict with existing node groups. Given the mutating nature and the lack of an output schema, more detail would help an agent execute correctly.

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

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

The schema already documents names, response_format, and assign_to_material with descriptions. The description adds value by implying the 'path' parameter refers to a .blend file, which is not stated in the schema. However, it doesn't elaborate on the interaction between parameters, such as how 'assign_to_material' works. Overall, it provides marginal additional meaning beyond the schema.

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

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

The description clearly states the action (append), the resource (shader or geometry node groups), and the source (another .blend file). It also gives the purpose (reuse existing shader library). It doesn't explicitly contrast with sibling tools like import_asset, but the specificity of 'node groups' and 'from another .blend file' makes the intent clear.

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

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

The description provides a general use case ('reuse an existing shader library instead of rebuilding graphs by hand'), but it doesn't compare with alternative tools or specify when not to use it. It implies a scenario but lacks explicit guidance on choosing this over sibling asset 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?

The description adds useful behavioral context by noting the result is 'permanent,' which goes beyond the annotations' bare mutation flags. However, it does not disclose that the modifier itself is removed, that undo may be needed for recovery, or what happens if the object has no matching modifier. No direct contradiction with annotations is present.

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 sentence with no filler: 'Bake a modifier's result into the mesh, making it permanent.' It front-loads the action and immediately conveys the key consequence.

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

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

For a mutation tool with no output schema and a required object parameter, the description is too thin. It omits how to identify the object, how modifier selection interacts with the stack, and what errors or results the agent should expect. The agent must already understand Blender's apply-modifier semantics 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?

The schema already documents the 'modifier' and 'response_format' parameters, but the required 'object' parameter is undocumented in both the schema and the description. The description does not clarify what object identifier should be provided or how the default modifier value behaves beyond what the schema states.

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

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

The description uses 'Bake' and 'making it permanent' to clearly identify the operation as applying a modifier's result to the mesh. It states the verb, resource, and outcome, though it does not explicitly distinguish itself from sibling tools like blender_add_modifier or blender_apply_transform.

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

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

No guidance is given about when to apply a modifier versus using alternatives such as blender_run_operator or blender_apply_transform. The description implies finalizing a modifier, but it does not state when this tool should be preferred or what prerequisites apply.

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

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

Annotations are all false, so the description carries the burden of behavioral disclosure. It clearly states that transforms are baked into mesh data, which implies a mutation of mesh data. It does not mention that the object's transform is reset to identity after baking, nor any prerequisites (e.g., objects must have mesh data). While the core behavior is clear, additional side effects are not disclosed, so a 4 is appropriate.

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

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

The description is two sentences with zero fluff. The primary action is front-loaded, and the usage context is immediately clear. Every word contributes to understanding.

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 tool with 5 parameters, no output schema, and no annotation guidance, the description is quite brief. It covers purpose and usage but omits important details such as whether the operation is reversible, what happens to the object transform after baking, and whether it applies only to mesh objects. An agent might call it incorrectly (e.g., on a non-mesh object) without knowing the constraints.

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% (only response_format has a description). The tool description does not explain any parameters – it does not clarify what 'objects' refers to, nor the meaning of scale, location, or rotation booleans. While parameter names are self-explanatory to Blender users, the description adds no value beyond the schema, and with low coverage it fails to compensate.

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: 'Bake transforms into mesh data' – this clearly distinguishes it from siblings like blender_set_transform (which sets object transforms) and blender_apply_modifier (which applies modifiers). It also names concrete use cases, making the purpose unambiguous.

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

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

The description explicitly states when to use this tool: 'before exporting' or 'when a modifier must see real geometry rather than an object transform'. This gives clear conditions and implies that other tools might be used otherwise. It effectively routes an agent to the right operation without needing to compare with 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?

Discloses the replacement behavior, which goes beyond the annotation flags. However, it doesn't clarify whether all material slots are replaced or just the active one, leaving some ambiguity.

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?

Single sentence, efficient, front-loaded with action and effect.

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, it lacks mention of error handling or prerequisites (e.g., material existence). The core action is clear, but it doesn't cover edge cases or return behavior. Adequate but incomplete.

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

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

Only response_format has schema description; objects and material lack descriptions. The description implies their roles but doesn't specify identifier formats or required naming conventions. Given low schema coverage (33%), more compensation is expected.

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

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

States a specific verb ('assign'), resource ('existing material to objects'), and the effect ('replacing their current slots'). It clearly distinguishes from material creation and listing siblings.

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

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

Clear context: you assign an existing material. However, it doesn't explicitly mention alternatives like blender_create_material for new materials, nor any exclusions, so it lacks explicit when-not guidance.

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

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

Annotations indicate this is not read-only, not idempotent, and not destructive. The description adds context by stating that objects remain linked to other collections, clarifying that the operation is additive and non-destructive. It also warns that the collection must already exist, which is not conveyed by the annotations. This goes beyond the structured data without contradicting it.

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

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

The description is concise—two sentences—with the primary action front-loaded. It immediately states what the tool does, then adds a prerequisite and a behavioral clarification. There is no redundant or extraneous content.

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 operation with two required parameters, the description covers the core action, the prerequisite (collection must exist), and the non-destructive behavior. It doesn't mention error handling or return format, but the response_format parameter has its own description and the tool is straightforward. The guidance to create the collection first implicitly covers the main failure mode, making it adequately complete.

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

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

Schema coverage is only 33% (response_format has a description; objects and collection do not). The description implicitly maps 'objects' to the list of objects and 'collection' to the target collection, but it does not provide explicit format details (e.g., object names, identifiers) or edge cases. Given the low schema coverage, the description partially compensates by stating the purpose but lacks explicit parameter-level explanations.

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 clear action: 'Add objects to an collection that already exists in the scene.' It specifies the resource (objects) and destination (collection), and further clarifies the semantic (adds a reference, not moving). This is specific and distinguishes it from other collection-related operations like creating a collection.

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 explicitly directs the agent to use blender_create_collection first if the collection is missing, providing a clear condition for using an alternative. It also explains the behavioral difference (adds a reference rather than moving), which helps decide between this and a potential move operation. While it doesn't enumerate all alternatives, the guidance is sufficient for the primary scenario.

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

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

Annotations already indicate a mutating, non-destructive operation. The description adds that framing is derived from object bounds, which meaningfully informs how lights are positioned. It doesn't disclose whether existing lights are cleared, but destructiveHint=false mitigates that concern.

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

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

Two concise sentences, front-loaded with the main action, and the second sentence adds a valuable detail about framing logic without any 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?

Covers the main behavior and framing rationale, but doesn't explain the 'apply' parameter semantics or behavior when 'objects' is null. Given 4 parameters and no output schema, some gaps remain for correct invocation.

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

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

Schema covers 75% of parameters with descriptions (style, objects, response_format). The description adds no additional parameter semantics beyond what the schema provides, 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?

States a specific verb ('Build') with a clear resource ('complete lighting rig') aimed at 'the subject'. The framing detail adds specificity and distinguishes it from individual light-adding tools like blender_add_light.

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?

Implied use for setting up scene lighting, but no explicit guidance on when to use this versus adding individual lights or other alternatives. No exclusions or conditions are provided, leaving the choice to inference.

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

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

With only negative annotations (not read-only, not idempotent, not destructive), the description adds useful context by explaining automatic projection selection and that the tool reports UV coverage. It does not, however, disclose whether existing UV layers are overwritten or what side effects the unwrap operation has on the mesh.

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 compact and front-loaded: the first sentence states the core purpose and output, and the second adds a practical rationale. Every sentence contributes useful information without redundancy.

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

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

The description captures the main purpose and a key default behavior, and the schema covers parameters well. However, with no output schema and sparse annotations, the agent would benefit from more detail on return values, prerequisites, or when to use a different UV-related tool. It is adequate but not fully complete.

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

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

Schema coverage is high at 83%, so the baseline is 3. The description adds value beyond the schema by explaining the behavior of the default `method`: it automatically picks a projection rather than simply using smart_project. This gives practical meaning to one of the key 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 clearly states a specific verb and resource: 'Unwrap meshes in one call and report the resulting UV coverage.' This is distinct enough from broad names like blender_uv, though it does not explicitly name or distinguish sibling tools such as blender_fix_uv_mapping or blender_uv.

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

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

The description implies a usage context: automatic projection selection is useful for mixed hard-surface and organic meshes, avoiding hand-picking per object. However, it does not explicitly say when to prefer this tool over alternatives or when not to use it.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, but the description states that it can 'repair' problems when apply_fixes=true. This contradicts the readOnlyHint, as fixing is a mutation. The description does not disclose potential side effects, irreversibility, or the need to save the file, which are critical for a write-capable tool. This is an annotation contradiction.

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

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

The description is concise (two sentences) while packing substantial information: the tool's purpose, optional fixing capability, and the problem domain it addresses. It is front-loaded with the core action and context, making it easy to scan.

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 tool with no output schema, the description does not explain the structure of the audit report beyond the response_format parameter. It also omits key behavioral details: what happens when fixes are applied (e.g., whether the .blend file is saved), and the meaning of 'unambiguous' in practical terms. The complexity is moderate, so more explicit guidance on expected outcomes would improve 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?

The schema already covers all parameters with descriptions (100% coverage), including apply_fixes and quick. The description adds context by mentioning that fixes are applied to 'problems that have an unambiguous fix', which clarifies the scope of apply_fixes, but otherwise relies on the schema for parameter meaning. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool audits a generated model end-to-end and can optionally repair problems with unambiguous fixes. It lists the specific domains covered (topology, UVs, materials, scale, naming) and positions it for the 'is it usable' question, distinguishing it from generic validation or mesh analysis tools.

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

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

The description explicitly frames when to use it ('I just generated this, is it usable'), which guides the agent to invoke it for end-to-end validation after generation. It does not explicitly exclude alternatives like blender_validate or blender_find_problems, but the focused scope of repairing unambiguous fixes and covering multiple aspects makes the usage context clear.

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

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

It discloses that the operation writes image files to disk and that on failure the result says so and why instead of raising an exception. Since annotations only cover read-only/destructive hints, this added failure-behavior detail is valuable and goes beyond what the structured data provides.

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

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

Two sentences carry the full message with no filler: purpose, prerequisites, engine recommendation, and failure behavior. The most important information is front-loaded.

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

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

The description covers prerequisites, engine choice, output, and failure behavior, which is sufficient for a moderately complex tool. Minor gaps remain around output_dir default behavior and file naming, but the core information an agent needs to select and invoke the tool correctly is present.

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

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

The description adds no parameter-level meaning beyond what the schema already provides. With schema description coverage at 80%, the baseline is 3; the description does not clarify ambiguous parameters such as 'size' or the behavior of an empty output_dir.

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

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

The description opens with a specific verb and resource: 'Bake a material's procedural node setup down to image files on disk.' This clearly distinguishes the tool from siblings like blender_render or blender_generate_texture by identifying both the input (procedural node setup) and the output (image files on disk).

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 states clear prerequisites ('Needs UVs and a node-based material') and recommends Cycles as the reliable engine, giving the agent useful context for when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.

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

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

The annotations are all false and provide little behavioral signal, so the description carries the burden. It discloses key runtime behavior: results come back per step, one failure does not hide successful steps, and arbitrary addon commands are dispatched. This is genuinely useful beyond the schema, though it does not detail output shapes or side effects of individual commands.

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?

Every sentence earns its place: definition, step format, result semantics, use-case justification, and the critical command-naming caveat. The layout is scannable and front-loads the most important information first, with no filler or redundancy.

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

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

Given no output schema and neutral annotations, the description gives an agent enough to invoke the tool sensibly: how to structure steps, what command namespace to use, and what to expect from failures. It could be more complete by listing the full set of accepted addon command names or the exact result envelope, but the examples and per-step behavior note are sufficient for a generic batch runner.

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 baseline is 3. The description repeats and slightly clarifies the steps structure and the example command names, adding the useful note that command names are not the tool names. However, it does not materially expand on stop_on_error or response_format, which are already well documented 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?

The description opens with a specific verb and resource: 'Run many bridge commands in a single round trip.' It clearly distinguishes itself from the many single-command sibling tools by emphasizing batching, and it reinforces this with concrete command-name examples. There is no ambiguity about what the tool does.

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

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

The description gives clear context: use this when building a scene efficiently, because it collapses dozens of round trips into one. It also warns that command names are the addon's names, not the tool names, which prevents a likely misuse. It does not explicitly name individual alternatives or state when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds valuable behavioral context by specifying the output contents (user counts, orphans, library info) that an agent would need to decide if this tool fits the task.

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

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

Two sentences, no fluff, with the core action and output details front-loaded. The usage guidance is appended as a second sentence, keeping the structure efficient.

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

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

For a read-only inventory tool with optional parameters and no output schema, the description captures the essential purpose and the type of data returned. It could mention output format, but the response_format parameter already covers that, so it's sufficiently complete.

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

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

Schema coverage is 100% – both parameters are described in the schema (types and response_format). The description adds no extra nuance about parameters, 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 states a clear verb ('inventory') and resource ('every datablock in the file') with specific details (user counts, orphans, library origin). It distinguishes itself from siblings like blender_list_libraries by focusing on datablock-level inventory rather than library-level listing.

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

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

It provides explicit context: 'before merging or cleaning it' – a clear when-to-use scenario. However, it does not name alternatives or explicitly state when not to use it, though the 'fastest way' phrasing implies preference.

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

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

Beyond the annotations (readOnly=false etc.), the description discloses that socket names follow real Blender naming so manual knowledge transfers, and that graph construction is resilient—errors are reported per node rather than failing the whole graph. It does not cover all side effects, but the annotations already place the bar lower.

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

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

Four short sentences, each carrying information: purpose, use case, naming compatibility, and error behavior. No filler, front-loaded.

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

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

For a complex node-graph builder, the description covers purpose, when to use it, naming semantics, and failure behavior, while the schema covers all parameters. It does not specify return format or side effects on existing materials, but annotations and schema compensate enough.

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

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

Schema coverage is 100% and already documents the meaning of nodes, links, assign, and response_format. The description reinforces real Blender socket naming but does not add new parameter-level semantics beyond the schema, 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 opening sentence uses a specific verb and resource ('Build an arbitrary shader node graph from a declarative description') and immediately frames it as the full-control path, distinguishing it from preset-based shader material tools among the siblings.

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

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

It provides an explicit condition ('when a preset is not enough') and explains advantages (full control, real socket names, per-node error reporting), but it does not name the alternative preset tools or explicitly say when not to use it.

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

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

The description discloses that the tool alters camera aim and can pull the camera back to fit a target, which is relevant beyond the annotations. Annotations already signal read-only=false and destructive=false, so the mutation is not surprising, but the description does not mention side effects like selection/activation or undo 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?

The core purpose is front-loaded in a short first sentence. The second sentence adds context about why the tool is useful, though 'a lot of blind iteration' is slightly informal and not strictly necessary.

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

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

The schema covers all parameters and annotations provide safety hints, but the description lacks explicit alternative routing and does not state what the tool returns or what happens with the active camera. It is adequate for a simple tool, but not fully complete.

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

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

Schema description coverage is 100%, so parameters are fully documented in the input schema; the description itself adds little beyond saying framing is optional. It broadly matches fit_distance and objects but does not explain parameter interactions beyond what the schema already provides.

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

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

The description names a specific verb and resource: 'Aim a camera at something and, optionally, frame it.' This clearly conveys the core action, though it does not explicitly differentiate from sibling tools like blender_look_at or blender_camera_move.

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 'why is my render empty' note implies a use case: when a render is empty because the camera is not aimed/framed. However, it gives no explicit when-to-use vs. alternatives and does not mention when not to use it or any prerequisites.

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

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the description is not contradicting them. The description adds useful behavioral context: orbit mode uses both keys and constraints so it renders deterministically, and it mentions that the orbit is a keyed turntable. However, it does not disclose side effects like whether existing camera animation is overwritten, whether constraints are permanently added, or whether the operation is destructive to prior keyframes.

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 compact and front-loaded with the main purpose and modes. The second sentence adds useful context about orbit being the quickest route and deterministic rendering. It is slightly terse given the tool's 13 parameters, but every sentence earns its place and 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 tool with 13 parameters, no output schema, and no required parameters, the description is somewhat thin. It explains the three modes at a high level but does not clarify how parameters like pivot, radius, target, up_axis, track_axis, or frame ranges interact with each mode. An agent would likely need to open the schema and infer mode-specific parameter usage, which is a notable gap for a complex animation 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 62%, so the schema already documents many parameters. The description adds a little semantic context by grouping modes (orbit, constraint, dolly) and explaining that orbit is keyed and deterministic, but it does not explain the meaning of several parameters like up_axis, track_axis, frame_start/frame_end, or response_format beyond their schema descriptions. It partially compensates for the 38% gap but not fully.

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 clear verb ('Animate the camera') and resource, and enumerates three distinct modes: orbit turntable, follow constraint, and two-point dolly. It distinguishes the orbit mode as the quickest route to a review turntable, which helps differentiate among the modes, though it doesn't explicitly contrast with sibling tools like blender_camera_focus or blender_look_at.

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

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

The description implies when to use the tool ('quickest route to a review turntable around a model') and hints at mode selection, but it does not explicitly state when to use this tool versus alternatives like blender_camera_focus, blender_look_at, or blender_set_active_camera. There is no explicit when-not-to-use guidance or mention of prerequisites such as an existing camera or scene.

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

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

Annotations provide readOnlyHint=false, implying possible side effects, but the description doesn't elaborate on file writes or state changes. It adds useful performance context and clarifies the return type (image). No contradiction with annotations.

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

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

Two sentences, front-loaded with the core action and minimal waste. The usage guidance is integrated efficiently.

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

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

The description omits how the returned image is delivered (e.g., markdown vs json), how output_path interacts with the result, and doesn't position the tool against blender_render. With no output schema and partial parameter coverage, an agent faces significant gaps.

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

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

Schema coverage is 50%, so the description should compensate for undocumented parameters. It merely reiterates the mode distinction already in the schema and provides no extra meaning for width, height, output_path, or response_format.

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

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

The description clearly states the tool's action ('Take a picture of what Blender is showing') and its role as a work-checking tool. It distinguishes internal modes (viewport vs render) but does not explicitly contrast with sibling tools like blender_render.

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

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

It gives explicit when-to-use guidance ('call it after a change and look at the result') and mode-selection advice ('viewport is nearly instant, render is the real deal'). It does not mention alternatives or exclusions, but the context is clear.

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

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

Annotations only provide generic mutating and non-destructive hints. The description adds concrete behavioral detail: it creates a named marker on the undo stack and establishes a coordination contract with `blender_undo`, which is more specific than the annotations alone.

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

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

The entire description is one well-structured sentence that front-loads the action and immediately explains its purpose, with no filler or redundancy.

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

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

For a simple optional-parameter tool, the core contract is complete: what is pushed, how it is labeled, and how it is used later. A note about the return value would be nice but is not critical given the tool's low complexity.

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

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

Schema coverage is 100%, so both parameters are already documented. The description reinforces the role of the label by calling it a 'named marker,' but does not need to add more parameter detail.

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: 'Push a named marker onto the undo stack.' It also names the exact consequence, allowing a later `blender_undo` to return to this point, which clearly separates it from the undo/redo siblings.

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

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

The intended usage is clear: create a checkpoint before work, then call `blender_undo` to return. The description does not explicitly list alternatives or when not to use it, but the condition under which it is useful is evident.

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

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

Annotations indicate a mutating, non-idempotent operation but do not explain what actually happens: whether existing connections are replaced, whether the material must already exist, or what side effects occur. The description adds only the direction of the connection and does not disclose behavioral traits beyond the implicit mutation.

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

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

The description is a single, front-loaded sentence with no filler or redundant content. Every word contributes to the core action.

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 tool with five required identifier parameters and no output schema, this description is incomplete. It does not state what counts as a valid node/socket reference, whether the connection replaces or adds a link, or what a successful result looks like. An agent would likely need to infer too much to invoke it reliably.

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 17%, so the description must compensate. It does clarify that 'from_node'/'from_socket' represent the output side and 'to_node'/'to_socket' represent the input side. However, it does not explain how nodes or sockets are identified or how the 'material' parameter is resolved, leaving significant ambiguity.

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 ('Connect') and resource ('output socket to an input socket inside a material'), making the tool's core function clear. It does not explicitly differentiate from shader-related siblings like blender_set_shader_input or blender_build_shader, but the socket-connection action is distinct enough to infer.

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 blender_set_shader_input or blender_build_shader. The description implies it operates within an existing material's node tree, but gives no conditions, prerequisites, or exclusions.

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

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

Annotations already indicate the tool is not read-only, not idempotent, and not destructive, so the mutation aspect is partially covered. The description adds context that the animation is procedural and intended for previews, but does not disclose what happens to existing animation data, whether keyframes are created, or what side effects occur beyond that.

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

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

The description is two short sentences with no filler. The primary action is front-loaded, and the second sentence justifies when the tool is useful without redundant detail.

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

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

The description gives enough context for basic selection: it is a procedural-animation generator for previewing rig motion. However, it omits what the generated output looks like, whether existing animation is replaced, and what qualifies as 'given objects' when combined with the objects parameter defaulting to selection. These gaps matter for a tool with no output 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?

With schema description coverage at 60%, the description has some burden to clarify parameters, but it adds almost no parameter-specific meaning. The phrase 'given objects' echoes the objects parameter, but it does not explain the type enum values or the frames/start_frame semantics beyond what their names imply.

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

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

The description uses a specific verb and resource: 'Generate a procedural animation on the given objects.' This clearly identifies the tool's function and scope. It hints at differentiation from 'real animation' workflows by mentioning previews and rig checking, though it does not explicitly name a sibling tool.

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

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

The description provides explicit context for when to use the tool: 'Useful for previews and for checking that a rig actually moves something before spending time on a real animation.' This is clear usage guidance, but it does not state when not to use it or mention alternative sibling tools by name.

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

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

Annotations already declare a non-read-only, non-idempotent, non-destructive operation, so the description carries less burden. It does add one behavioral fact beyond annotations: the tool can optionally move existing objects into the new collection. However, it does not disclose what happens when a collection with the same name already exists, whether moving removes objects from their previous collections, or what failure modes exist.

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

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

The description is a single 18-word sentence with no filler. The core action comes first, and the optional modifiers follow naturally. Every word earns its place.

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

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

For a mutation tool with no output schema, the description is lean. It explains the essential parameters but omits observable outcomes: return value, duplicate-name behavior, parent existence expectations, and side effects on moved objects. Given the number of sibling collection-related tools, an agent would need to infer too much to use this confidently.

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

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

Schema description coverage is only 25%, so the description must compensate; it partially does by clarifying `parent` means nesting and `objects` are existing objects to move into the collection. But `name` is left to its label, and behavior around invalid parent or object references is not described. The `response_format` parameter already has its own schema description.

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

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

The description states a clear verb ('Create') and resource ('a collection'), and adds two distinguishing behaviors: nesting under `parent` and moving existing objects into the collection. It is specific enough to be separated from `blender_assign_to_collection` by verb alone, though it does not explicitly name any sibling.

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

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

No guidance is given about when to choose this tool over alternatives. There is also nothing about prerequisites (e.g., whether the parent collection must already exist) or when a sibling like `blender_assign_to_collection` would be more appropriate. The only implied context is the purpose itself.

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

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

Annotations already signal that this is a mutating, non-idempotent operation, and the description neither contradicts them nor adds meaningful side-effect context. It does not explain what happens when a material with the same name exists, how 'overwrite' behaves, or whether assignment replaces existing material slots. The phrase 'optionally assign' is present but vague.

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

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

The purpose is front-loaded in a single clear sentence, and the example is compact and immediately usable. There is no filler or repeated schema information. The example earns its place by demonstrating realistic values and parameter relationships.

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 10 parameters, no output schema, and only sparse annotations, a two-sentence description plus example is insufficient. Missing behavioral details such as overwrite semantics, return value, and relationship to sibling material-assignment tools leave an agent under-informed for correct invocation.

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

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

Schema description coverage is only 20%, so the description carries extra responsibility. The example does add practical meaning for name, base_color, metallic, roughness, emission_color, and emission_strength by showing a coherent glowing-metal configuration. However, it leaves ior, overwrite, assign_to, and response_format unexplained beyond their schema names.

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

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

The description clearly states a specific verb and resource: 'Create a Principled BSDF material and optionally assign it to objects.' This is unambiguous and matches the tool name. However, it does not explicitly contrast with sibling tools like blender_assign_material or blender_set_material_node, so it stops short of full differentiation.

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

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

The description provides a concrete example but no guidance on when to use this tool versus alternatives. There are no mentions of exclusions, prerequisites, or why an agent should choose this over blender_assign_material or blender_generate_pbr_set. Usage context is only implied by the example.

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

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

Annotations already mark the tool as non-readOnly and non-idempotent, and the description's 'Create' is consistent with that. However, the description adds no extra behavioral context such as scene placement, name-collision behavior, or whether the new object becomes active/selected.

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

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

Two short sentences plus a focused code block; every clause adds information, and the face-loop clarification is directly useful. There is no filler, repetition, or unnecessary detail.

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?

It covers the face indexing rule well but leaves the vertex coordinate convention implicit and does not describe scene placement or optional parameter behavior. Given 7 parameters and no output schema, the description is adequate for a simple create call but not fully self-sufficient.

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

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

The description usefully clarifies the `faces` parameter, explaining zero-based vertex index loops and triangle/quad lengths. It does not explain the expected structure of `vertices` (e.g., [x, y, z] lists) or the semantics of `collection`, `material`, and `location`, and the schema itself only documents `response_format`, leaving most parameters without explanatory text.

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

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

The description uses a specific verb and resource ('Create a mesh object') and qualifies it with 'from explicit vertex and face data,' which clearly distinguishes it from primitive/operator-based mesh creation siblings like blender_add_primitive. It identifies exactly what the tool does.

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

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

The phrase 'from explicit vertex and face data' implies this is for custom geometry rather than primitives or editing, but the description does not name alternatives or state when not to use it. Usage context is present only by implication.

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

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

Annotations already mark the tool as not read-only and not idempotent, and the description adds that it can add/remove modifiers, shift frames, and scale values, which conveys mutation. It does not, however, disclose side effects or prerequisites such as requiring an existing action, and it doesn't contradict the annotations.

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

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

Three sentences with the core purpose first; the second sentence is somewhat abstract but earns its place by listing the operation families. No redundant restatement of the schema.

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

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

For an 11-parameter multi-operation tool with no output schema, the description is a useful overview but incomplete: it doesn't explain what each op returns, how to target a specific F-curve via data_path, or what object/action prerequisites exist. The schema fills many gaps, but an agent would still need to infer operational behavior.

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

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

With 91% schema description coverage, the schema carries most parameter meaning. The description adds value by grouping capabilities (interpolation/easing, handles, modifiers, retiming, scaling) that map to op and related parameters, and by clarifying that object refers to an object's action, but it doesn't detail individual parameter syntax or interactions.

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

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

The description opens with a specific verb and object: 'Inspect and shape the F-curves of an object's action.' This clearly identifies the resource and differentiates it from sibling tools that handle keyframes, NLA, or drivers. The second sentence reinforces scope by enumerating interpolation, easing, handles, modifiers, retiming, and value scaling.

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

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

The description implies the tool's niche—'where animation gets its character rather than just its timing'—and lists concrete use cases. However, it never names alternatives or states when not to use this tool, so an agent must infer the boundary against the many sibling animation 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?

The description explicitly states that deletion is permanent and cannot be undone from the MCP server, going beyond the destructiveHint annotation by emphasizing irreversibility and advising a save step. This adds valuable context that the annotation alone does not convey.

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

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

Two sentences, no fluff, and the critical warning is front-loaded. Every word 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 straightforward deletion tool, the description covers the essential caution (irreversibility and save advice). It does not describe return values or side effects beyond deletion, but for this simple operation it is sufficiently complete.

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

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

The description provides no information about the parameters. Schema coverage is only 50% (only response_format has a description), and the description does not compensate for the undocumented 'objects' array. An agent is left to infer what the objects parameter expects.

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 clear verb ('delete'), resource ('objects from the .blend file'), and permanence, making the purpose unambiguous. It does not explicitly name alternative tools, but among siblings it is the only delete operation, so it is easily distinguishable.

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

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

The description provides a critical usage warning ('save first if the scene matters') but does not specify when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The context is implicit from the name and description, but explicit routing to other tools is absent.

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

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

Annotations already carry readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not restate safety. It adds useful behavioral context by listing the exact categories checked and noting cost relative to full validation, though it does not describe the output/return shape.

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

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

The description is two short, purposeful sentences: the first front-loads the purpose with a tight list of checks, and the second gives a cost/usage comparison. No filler or repetition.

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

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

For a simple read-only health-check tool with one optional, fully documented parameter, the description is nearly complete. It covers what is checked and when to use it, but it does not explicitly describe the result format (list of issues, pass/fail summary) beyond what the response_format schema already hints 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?

The only parameter, response_format, is already fully documented in the input schema with enum values and descriptions (markdown for readable output, json for raw structured data). The description adds no additional parameter-level meaning, 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?

The description states a specific diagnostic purpose ('Quick health check on the project') and enumerates the concrete issue categories it detects (missing camera, unpacked textures, orphan datablocks, etc.). It also contrasts itself with a 'full validate', which differentiates it from the heavier validation sibling.

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

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

It explicitly tells the agent when this tool is appropriate: when you just want to know what is wrong, and that it is cheaper than a full validate. This gives a clear selection rule versus the validate/check 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?

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds valuable behavioral context beyond annotations: it explicitly states the download is size-capped, only http/https are allowed, and nothing downloaded is ever executed. It also mentions the tool reports size and SHA-256, which is a behavioral outcome. This goes beyond what annotations alone convey, though it doesn't detail failure modes or side effects like file overwriting.

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

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

The description is three sentences with zero waste. The core action is front-loaded in the first sentence, safety constraints follow, and the workflow suggestion is last. Every sentence earns its place, and the structure is easy to scan.

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 tool with 7 parameters and no output schema, the description covers the essential context: what it does, safety constraints, and how it fits with a sibling tool. It doesn't explain return values in detail, but the description already states it reports size and SHA-256, which is sufficient for an agent to know what to expect. The main gap is not describing what happens on checksum mismatch or file overwrite behavior, but the schema's sha256 description covers the mismatch case.

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 already documents most parameters. The description adds context that the download is size-capped and reports SHA-256, which maps to max_bytes and sha256 parameters. It also clarifies the tool's role in a pipeline (combine with blender_import_asset), which helps an agent understand why parameters like directory and filename matter. However, it doesn't add detail on timeout or response_format beyond what the schema provides, so a 4 is appropriate rather than 5.

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

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

The description states a specific verb and resource: 'Fetch a URL to a local file and report its size and SHA-256.' It clearly distinguishes this from sibling tools like blender_import_asset by noting it only downloads and does not execute, and it explicitly suggests combining with blender_import_asset for a full workflow. This makes the tool's purpose unambiguous.

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

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

The description explicitly says when to use this tool ('Combine with blender_import_asset to pull a model straight onto the scene') and what it is not for ('nothing downloaded is ever executed'). It also states constraints (only http/https, size-capped) that guide safe usage. This is strong guidance for an agent deciding between download and import 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?

The description goes beyond the annotations by explaining that passing `apply_to` will import and attach the result in the same call, which is useful side-effect information. It does not clarify network/download behavior, what happens on failure, or whether search alone is side-effect-free, but the annotations already indicate non-read-only, non-destructive, open-world behavior, so the added context earns a baseline-3 score.

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

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

The description is only two sentences and wastes no words. The primary search/list purpose is front-loaded, and the optional attachment behavior is presented as a separate, clearly conditional second sentence.

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

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

The description is adequate for a search/list tool with annotations and good schema coverage, but it lacks some important context: it does not describe the return structure, clarify whether calling without `apply_to` truly avoids all scene changes, or explain the relationship between 'search,' 'download,' and 'import.' These are meaningful gaps for a tool that can perform side effects.

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

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

Schema description coverage is 80%, so the input schema already documents most parameters. The description adds a small amount of value by explaining the behaviorally important `apply_to` parameter, but does not add meaning for `query`, `source`, `limit`, or `response_format` beyond what the schema already provides.

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

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

The description uses a clear verb and resource: 'Search downloadable animation sources and list what is available.' It also discloses the optional import/attach behavior via `apply_to`. However, the name suggests 'download' while the description emphasizes 'search/list,' leaving some ambiguity about whether assets are actually downloaded; it also does not explicitly distinguish this from sibling tools like blender_download or blender_download_textures.

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 no guidance on when to use this tool versus alternatives such as blender_download_textures, blender_download, or blender_create_animation. The only usage direction is 'Pass apply_to to import and attach the result in the same call,' which is parameter behavior rather than tool-selection guidance.

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

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

Annotations say readOnlyHint=false and destructiveHint=false, and the description doesn't contradict them; it explains the side effect of wiring results onto objects via apply_to. However, it doesn't disclose other behavioral traits such as file downloads, material creation, network dependence, or licensing/rate limits, which are material to such a 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 sentences, all informative; the core action is front-loaded and the apply_to tip earns its place. No waste.

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

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

The description explains the core search-and-download function and the apply_to option, which is enough for a rough call. But with no output schema, it omits return/response behavior (markdown vs json) and doesn't clarify what 'download' produces (files, materials, nodes), leaving gaps for an agent deciding on parameters and handling 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?

With 80% schema coverage, the schema already documents query, library, apply_to, and response_format. The description adds only the 'wire the result onto objects' nuance for apply_to, and nothing about limit or library/default behavior, so it adds minimal value beyond the schema.

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

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

States a specific action: search a free PBR texture library and download matching maps. It clearly identifies the resource (PBR texture library) and outcome (downloaded maps), and also notes the apply_to behavior. However, it doesn't explicitly contrast with sibling tools like blender_generate_texture or blender_load_image_texture, so an agent must infer its niche from 'free' and 'download'.

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 implied scenario (wanting real-world PBR textures from a free library) and includes a targeted instruction for apply_to. But it never names alternatives or states when not to use it (e.g., when you need procedural generation or existing images), so routing is left to inference.

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

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

Annotations already indicate this is a mutation tool (readOnlyHint=false, destructiveHint=false). The description adds the purpose and a feature ('real typed variables') but does not disclose side effects, prerequisites (e.g., active object), or whether existing drivers are overwritten. No contradiction with annotations, but the added behavioral context is minimal.

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

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

The description is two concise sentences with no filler. It leads with the main action and then provides illustrative examples, maximizing informativeness per word.

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?

While the description is clear on purpose and use cases, it lacks detail on several important aspects: the meaning of 'object' and 'data_path', the return format of 'list', and how to structure variables. With 8 parameters and no output schema, the description is not fully complete, though it provides a reasonable starting point.

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%, so most parameters are documented in the schema. The description adds meaning to 'variables' and 'expression' ('real typed variables and expressions') but does not clarify 'object' or 'data_path', which are undocumented in the schema. Since it does not fully compensate for the two missing descriptions, a 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 states a clear verb–resource pair ('Add, list or remove drivers') and emphasizes 'real typed variables and expressions', which distinguishes it from sibling keyframe/animation tools. It also gives concrete examples (spin a wheel, bob with a sine), making the purpose immediately understandable.

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

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

The description provides usage context by stating it's 'useful for procedural motion that should not be baked', implying when to prefer it over keyframes. However, it does not explicitly name alternatives or give 'when not to use' conditions, so it falls short of a 5.

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

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

Annotations already indicate the tool is not read-only, not idempotent, and not destructive, so the safety profile is covered. The description adds the behavioral detail that the copy is 'independent', meaning changes to the copy will not affect the original, which is useful context. However, it does not disclose whether new objects are created in the scene, how collection assignment works, or any side effects. Given annotations, a 3 is appropriate—it adds some value but not extensive behavior 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 description is a single, focused sentence that immediately states the action and key nuance. It is front-loaded, avoids filler, and every word contributes to understanding. Length is appropriate for the tool's simplicity—no unnecessary detail or repetition.

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

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

For a relatively simple tool with three parameters and no output schema, the description is minimally adequate. It explains the core function but omits details like where duplicates are placed, how the collection parameter influences the operation, and what the response will contain. Given the low parameter coverage and absence of output schema, the description feels incomplete for an agent that needs to invoke it correctly without further 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 only 33% (only response_format has a description), and the tool description does not elaborate on any parameter. The description 'Duplicate objects' implies that the 'objects' parameter is the list to duplicate, but 'collection' remains completely unexplained—its role in placing duplicates is unknown. With low schema coverage, the description should compensate but does not, leaving key parameters under-specified.

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 ('Duplicate') and resource ('objects'), and adds a key detail ('together with their mesh data (an independent copy)') that clarifies the scope and behavior. It clearly distinguishes from sibling tools like delete, rename, or join, which are semantically different. No ambiguity about what action is performed.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives, such as when a simple duplicate is needed versus using blender_run_operator or scripting. There are no conditions, prerequisites, or exclusions. The intended usage must be inferred from the action itself, which is insufficient for an agent deciding between 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?

Annotations indicate this is a mutating, non-idempotent, non-destructive operation. The description adds valuable behavioral details beyond annotations: the selection scope (unless region='all') and the return of vertex/edge/face counts before and after. This clarifies side effects and expected output.

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

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

The description is two sentences, front-loaded with the core purpose and a concrete list of actions. Every sentence earns its place, with no filler or redundant information.

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

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

Given the complexity (many actions, open-ended parameters, no output schema), the description covers the core purpose and selection scope but lacks per-action parameter guidance. It mentions return counts but does not detail all parameter semantics. The schema provides partial coverage, so overall it is adequate but not exhaustive.

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 67%, so the description does not need to fully compensate. It adds meaning to the region parameter (selection scope) and hints at the action list, but objects, distance, and parameters are not elaborated. The description offers modest added value beyond the schema.

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

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

The description clearly states the tool's purpose: editing mesh topology with a list of specific operations (extrude, bevel, inset, subdivide, etc.). It names the resource (mesh) and the action, making it unambiguous and distinguishing it from creation or generic operator tools.

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

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

The description provides context on when it operates ('current edit-mode selection inside the object unless region='all'') but does not explicitly mention when to use this tool instead of alternatives like blender_create_mesh or blender_run_operator. The usage is implied rather than explicitly guided.

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

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

The annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description says 'Execute arbitrary Python inside Blender' and demonstrates code that creates an object via bmesh and bpy. Arbitrary Python can mutate state, so the description contradicts the annotations and presents a false safety model to the agent.

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 front-loads the core purpose, then gives usage context, available names, and one instructive example. No sentence is filler; the example earns its place by showing a complete object-creation and result-return pattern.

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 arbitrary-code tool with no output schema, it covers return variants, imports, and the view3d context, which is good. However, it fails to counter the misleading read-only/non-destructive annotations by warning that executed Python may modify Blender scene state, leaving the operational picture incomplete and unsafe.

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

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

With schema coverage at 67%, the description adds meaningful semantics mainly for the `code` parameter: available namespaces, the `Result(...)` pattern, and a full bmesh example. `capture_output` and `response_format` are already documented in the schema, so the added parameter guidance is solid but not exhaustive.

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

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

The description opens with a specific verb and resource: 'Execute arbitrary Python inside Blender' and a clear return contract ('stdout, the expression value, or the traceback'). It also labels itself 'the general escape hatch' for areas dedicated tools do not cover, which separates it from the many specialized sibling tools.

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

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

It explicitly states when to use: 'use it for anything the dedicated tools do not cover' and provides concrete use cases such as node graphs, drivers, custom rigging, numpy-style math, and bmesh work. This strongly implies the inverse—prefer dedicated tools when one applies—without needing further elaboration.

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

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

Annotations already signal a non-read-only, world-opening operation. The description adds valuable behavior beyond annotations: per-format processing details (fbx bakes modifiers and embeds materials, glTF exports textures, obj preserves normals/UVs) and an explicit guarantee to fail rather than falsely report success when no file appears. It does not discuss file overwriting or permissions, but the bar is lower given annotations cover the safety profile.

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

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

The description is three sentences, each earning its place. Purpose is front-loaded, format defaults are compactly summarized, and the failure behavior is a single efficient sentence. There is no repetition or 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 tool with five parameters and a nested export_options object, the description covers the main purpose and format nuances but leaves gaps. It does not distinguish from the sibling blender_export_model, does not explain the required path parameter, and, with no output schema, does not describe what the response contains. These are meaningful omissions for a moderately complex 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 80%, so the baseline is 3. The description adds meaningful meaning for the format parameter by explaining what each exporter does by default, and it clarifies the objects parameter's scope. There is a slight mismatch where it says 'scene or a named set' while the schema says the default for objects is the selection, but overall it still adds value beyond the schema.

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

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

The description opens with a specific verb, 'Export,' and identifies both the resource (scene or a named set of objects) and the outcome (a model file). This clearly distinguishes it from import-oriented tools. However, it does not differentiate it from the closely named sibling blender_export_model, so it falls short of a 5.

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

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

The description implies the tool should be used when exporting a scene or selected objects to a model file, giving clear context. It offers format-level defaults that shape behavior, but it provides no explicit when-to-use/when-not-to-use guidance and never mentions alternatives such as blender_export_model.

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

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

Annotations indicate readOnlyHint=false and openWorldHint=true, but the description adds no further behavioral context. It does not mention side effects like file overwriting, whether a scene must be loaded first, or what happens with existing files. The description only restates the obvious export action, adding minimal value beyond annotations.

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

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

The description is a single sentence, wastes no words, and clearly enumerates supported formats. It is front-loaded with the core purpose and efficiently conveys exactly what the tool does.

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 export tool, the description covers the basic functionality and formats, but omits details on return values (no output schema), filename/extension handling, and overwrite behavior. It does not mention the response_format parameter, leaving some gaps in what an agent might need to know for successful invocation.

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

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

The description does not elaborate on any parameters. Schema coverage is 75%, with the path parameter lacking a description. The tool description neither mentions how to specify formats nor selection, leaving agents to infer from parameter names and their property descriptions. It adds no semantic value over 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 clearly states the action 'Export', the resource 'scene', and enumerates accepted output formats (.glb, .gltf, .fbx, .obj, .stl, .ply, .usd, .abc, .blend). This distinguishes it from the sibling import tool and other scene manipulation tools. It is specific and not a tautology.

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

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

The description implies usage (export a scene when a model file is needed) but provides no explicit guidance on when to use this tool over alternatives like blender_import_model, nor any prerequisites such as requiring a selected object. It lacks any when-not or alternative routing.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds useful behavior by explaining that an HDRI becomes the world lighting and that the asset can be optionally used. It does not describe side effects for textures/models in detail, but the central behavior is disclosed and consistent with annotations.

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

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

The description is short and front-loaded, with the core action stated first and the HDRI value proposition in a compact second paragraph. Every sentence earns its place, and there is no redundant repetition of the tool name or schema fields.

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

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

The HDRI path is well covered, but the description remains vague about textures and models: what 'use' means for those asset types, what the tool returns, and how it relates to searching or downloading. With 9 parameters and no output schema, additional context would be needed for an agent to invoke it correctly across all asset categories.

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 56%, so the description needs to add some param semantics. It reinforces the meaning of id and library and clarifies the HDRI/world-lighting behavior linked to type and set_as_world. However, parameters like rotation and strength have no description coverage in the schema and are also not explained in 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?

The description uses a specific verb and resource ('Download an asset from a library by id') and clarifies that the asset may optionally be used afterward. It is clear, but it does not explicitly differentiate this tool from sibling tools such as blender_download or blender_import_asset.

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 HDRI sentence provides a concrete use case: fetching an HDRI and making it the world lighting in one call is the fastest route to a believable render. It gives clear context for when to use it, though it does not name alternatives or state when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=falseags. The description adds meaningful behavioral context about the default restricted roots and explains that allow_anywhere is off by default because an agent that can read the whole disk is a liability. This goes beyond what annotations alone communicate.

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

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

The description is extremely concise: two short sentences front-load the main action and scope, then deliver the critical usage warning. 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?

For a read-only list/search tool, the description covers the default roots coordinates, the key security caveat, and relies on the schema for path/pattern/roots handling. There is no output schema, so return format details are not specified, but response_format is available in the input schema, making this adequately 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 83%, so the schema already documents most parameters. The description adds value by naming the default allowed roots and reinforcing the caution around allow_anywhere, complementing the schema's existing parameter descriptions.

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

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

The description clearly states the action ('List or search files') and the resource scope (home directory, Blender's script folders, asset cache). It is specific about what the tool does, though it does not explicitly differentiate it from sibling tools like blender_scripts_and_texts or blender_download.

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

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

The description gives a clear operational context: restricted roots by default, and explicit guidance to pass allow_anywhere only when the user has actually asked for it. It doesn't compare this tool to alternative sibling tools, but the default behavior and caution are enough for selecting it appropriately.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by explaining that the tool returns an 'actionable' list pairing problems with resolving tool calls, which goes beyond the annotations. It does not contradict the annotations, and it provides useful information about the output format.

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

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

The description is two concise sentences with no waste. The opening comparison to blender_validate immediately orients the agent, and the usage guidance follows directly. Every sentence earns its place, making it easy to parse quickly.

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 validation tool with no output schema, the description explains the return format ('actionable' list pairing problems with fixes) and the usage context. It doesn't detail all parameters, but the schema covers 80% of them. The description is sufficient for an agent to know what to expect and how to use it, though it could mention edge cases like empty results.

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

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

Schema description coverage is 80%, meaning most parameters have descriptions in the schema. The tool description itself adds little about parameters beyond the schema, mentioning the 'actionable' list but not parameter specifics. With high coverage, the schema handles most semantic burden, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool's function: it's like blender_validate but returns only failures, each with a concrete fix. It also frames the purpose as 'act rather than read', distinguishing it from the sibling validation tool. This gives an agent a precise understanding of what the tool does and how it differs.

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 explicitly says 'Use this when you want to act rather than read', providing a clear usage condition. It contrasts with blender_validate, implying that blender_validate is for reading/understanding while this tool is for actionable fixes. However, it doesn't explicitly mention when not to use it, such as when a full validation report 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?

The annotations declare destructiveHint=false, but the description explicitly says the tool will 'delete loose geometry', which is a destructive modification. This is an annotation contradiction, and the description provides no safety caveats or side-effect disclosure beyond that.

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

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

The description is a single front-loaded sentence that states the purpose, lists the concrete operations, and notes the output reporting. There is no filler or repeated information from the schema.

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

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

The description covers the core operations and the before/after reporting, and the schema covers the selection default. However, it omits prerequisites, when to run the repair, and important safety context, especially given the deletion behavior and the absence of an output 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 60%, and the description helps map weld_distance to merging, recalc_normals to recalculating, and remove_loose to deleting loose geometry. However, it adds nothing meaningful about the 'objects' parameter or response_format, and does not specify units or thresholds for weld_distance.

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

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

The description clearly states the action ('repair'), the target resource ('mesh problems'), and the specific operations (merge duplicate vertices, recalculate normals, delete loose geometry), plus the reporting behavior. This distinguishes it from sibling tools like blender_fix_uv_mapping or blender_auto_validate.

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

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

The description implies when to use the tool: when a mesh has duplicate vertices, bad normals, or loose geometry. However, it gives no explicit guidance on when not to use it, no prerequisites, and no mention of alternative sibling tools, which is needed given the large set of Blender repair/validation 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?

Annotations already indicate this is a mutating, non-idempotent operation, so the description does not need to restate that. It adds value by noting that the tool reports what changed per object, but it does not disclose side effects like overwriting existing UV maps or how the repair interacts with materials/textures.

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

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

The description is two sentences with no filler. The primary action and scope are front-loaded, and the reporting behavior is stated succinctly. Every word 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 tool with five optional parameters and no output schema, the description communicates the core operation and the reporting behavior clearly. The schema covers object targeting and response format, so the agent has enough to call it correctly, though more detail about the repair methods and their effects would improve 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?

The tool description adds no parameter-level detail beyond the schema. The schema itself documents objects and response_format reasonably, and method has a minimal description, but margin and angle_limit_deg rely on their self-explanatory names. With 60% schema coverage, the description does not need to compensate heavily, but it also contributes nothing.

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 ('Repair'), a clear resource ('UVs on existing meshes'), and the exact problem scope ('stretched, overlapping or out-of-range'). It also promises a distinct outcome ('report what changed per object'), which clearly separates it from generic UV tools like blender_auto_uv or blender_uv.

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

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

The description implies when to use the tool: when UVs are stretched, overlapping, or out-of-range on existing meshes. However, it does not explicitly state when not to use it or mention alternatives such as blender_auto_uv for creating fresh UVs, leaving some routing to inference.

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

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

Annotations only provide risk flags, so the description adds useful behavior: it creates copies, places them in a collection, and reports original versus generated face counts. This makes the non-destructive, reporting-oriented behavior visible, though it does not address behavior around existing LOD collections or default selection.

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

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

Two tight sentences: the first states the action and outcome, the second explains the value of the reports. There is no filler, and important information is front-loaded.

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

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

The description gives a solid overview and mentions the face-count output, but with no output schema it leaves some ambiguity around what 'objects: null' means and how existing LOD collections are handled. It is adequate but not fully self-sufficient.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context around decimation and face-count reporting but does not add parameter-level guidance beyond what the schema already provides.

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

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

The description states a specific action ('Create decimated LOD copies of meshes') and a concrete result ('put them in a LOD collection'). It is clearly distinguishable from siblings like blender_duplicate_objects or blender_add_modifier because decimation and LOD collection organization are unique to this tool.

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

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

The description implies the tool is for generating LODs but gives no explicit guidance on when to use it over alternatives, no exclusions, and no conditions. An agent must infer the intended use case from the tool name and basic action.

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

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

Annotations only state readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds meaningful behavioral context: BaseColor is written sRGB while data maps are Non-Color, all maps come from one shared height field and seed, and passing `material` adds an AO multiply onto Base Color. It does not disclose file-output side effects or return behavior, but it goes well beyond the annotations.

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

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

The description is three concise sentences with no filler. The first sentence states the core purpose, the second explains the generation consistency and color-space behavior, and the third gives the material-wiring option. Useful information is front-loaded and every sentence earns its place.

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

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

For a 16-parameter tool with low schema coverage and no output schema, the description leaves important gaps. It never explicitly states that files are written to output_dir, what the response contains, or how the procedural parameters interact with the shared height field. It is sufficient for a default or simple invocation, but not for informed custom use.

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 38%, leaving most of the 16 parameters undocumented. The description adds some meaning for `seed` (all maps derive from one seed) and `material` (wires maps into a Principled BSDF with AO multiply), but it does not compensate for the many procedural parameters an agent would need to tune, such as scale, octaves, pattern, contrast, roughness range, metallic, or normal_strength.

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

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

The description starts with the specific verb 'Generate' and names five concrete map types: BaseColor, Roughness, Metallic, Normal, and AO. It further distinguishes the tool by explaining that all five maps derive from one height field and one seed, making them read as a single material. This clearly separates it from texture-generation siblings like blender_generate_texture or blender_bake_texture.

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 clearly frames when to use the tool: when a matched PBR set is needed, and it gives conditional guidance for the `material` parameter ('Pass material to connect everything...'). It does not explicitly name alternatives or state when not to use this tool, which keeps it one step below a perfect score.

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

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

Annotations only say readOnly=false, idempotent=false, destructive=false. The description adds the key side effect: it writes a real PNG to disk and clarifies the result is a normal, inspectable, shippable file, not a viewport-only effect. It does not mention overwrite behavior or datablock creation, but it adds meaningful behavior beyond annotations.

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

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

The description is two short paragraphs, front-loaded with the action and output. The 'useful for' list is relevant and the final sentence adds behavioral clarity without padding. Every sentence earns its place.

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

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

For a 13-parameter tool with no output schema, the description plus rich schema covers the essentials: what it produces, where it writes, and that it is a real file. It does not describe the response payload, but the response_format parameter and schema descriptions fill most 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 92%, so the schema already documents nearly all parameters. The description adds a little color by naming example patterns that map to the pattern enum, but it does not explain parameter semantics beyond what the schema provides. 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 and resource: 'Generate a procedural texture and write it to a real PNG on disk.' It clearly distinguishes the tool from viewport-only effects and, combined with the listed use cases, makes the function unambiguous.

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

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

The description gives concrete use cases ('plate text, hazard stripes, carbon weave, rust, brushed metal, leather grain and similar'), which implies when to use the tool. However, it does not state when to prefer a sibling like blender_bake_texture or blender_generate_pbr_set, nor does it provide exclusions.

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

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

Annotations provide no safety hints (all false), so the description carries some burden. It adds one useful behavioral detail: 'Edit-mode operations restore object mode automatically, even if the operator raises,' which is helpful. However, it does not disclose side effects, error behavior, or other operational nuances, so the transparency is limited.

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

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

The description is concise, with two short paragraphs. It front-loads the purpose and lists operations efficiently. There is no wasted wording, though it could be more structured with explicit parameter mappings.

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 tool with 20 parameters and 14 distinct operations, the description is far too sparse. It does not explain return formats, error handling, how to select objects, or how to pair parameters with operations. Given no output schema and limited parameter documentation, the description is inadequate for an agent to reliably invoke the tool correctly.

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

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

With 20 parameters and 55% schema coverage, the description does not explain parameter usage at all. It merely lists operations, leaving the agent to guess which parameters apply to which operation. The schema provides some per-parameter hints, but many parameters (e.g., clip, merge, bisect, radius) lack context. The description fails to compensate for the schema 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 clearly states the tool performs 'Geometry operations' and lists a comprehensive set of specific operations (mirror, array, solidify, etc.), distinguishing it from the 'generic modifier tool' and other sibling tools. It is specific and unambiguous.

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

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

The description notes these are operations 'that do not fit the generic modifier tool,' which gives an implicit usage boundary. However, it does not explicitly mention alternative tools or conditions for when to use this over them, such as blender_add_modifier or blender_edit_mesh. The guidance is minimal.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the scope of what is returned (transforms, hierarchy, materials, etc.), which is useful behavioral context. However, it does not disclose details like whether the object must exist, what happens if the name is not found, or whether the world matrix is computed or stored. With annotations covering the safety profile, a 3 is appropriate.

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

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

The description is a single, information-dense sentence that front-loads the verb and resource, then enumerates the data categories. Every phrase earns its place, and there is no wasted wording or repetition of schema details.

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

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

For a read-only inspection tool with annotations covering safety and a clear list of returned data categories, the description is largely complete. The main gap is the lack of error behavior (e.g., what happens if the object name does not exist) and any note about performance or large scenes. However, given the tool's simplicity and the absence of an output schema, the description provides enough for an agent to select and invoke it correctly in most cases.

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

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

Schema description coverage is 50%: the 'name' parameter has no description beyond its title, while 'response_format' has a description. The tool description does not add meaning to the 'name' parameter beyond implying it identifies the object. The 'response_format' parameter is already well-documented in the schema. The description compensates somewhat by listing what data is returned, but it does not clarify the format or constraints of the 'name' parameter (e.g., exact name vs. partial match).

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

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

The description uses a specific verb ('Get') and a clear resource ('one object'), and enumerates the exact categories of data returned: transforms, hierarchy, materials, modifiers, constraints, mesh statistics, custom properties, and world matrix. This distinguishes it from sibling tools like blender_list_objects (which lists objects) and blender_get_scene (which gets scene-level data).

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

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

The description implies this is the tool to use when you need comprehensive object data, but it does not explicitly state when to use it versus alternatives like blender_list_objects, blender_get_scene, or blender_analyze_mesh. There is no explicit exclusion or alternative routing, though the scope ('one object') and the data categories provide some implicit guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's silence on side effects is acceptable. It adds useful context about the detailed flag expanding per-object data, but it does not disclose output size or latency implications of requesting detailed data. No contradiction with annotations.

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

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

Two front-loaded sentences with a compact Args section and no filler. Every sentence earns its place: the first specifies scope and contents, the second explains the optional detailed flag.

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

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

For a simple, read-only, zero-required-parameter tool, the description is adequate: it defines the return scope and the optional flag, while annotations cover safety. Without an output schema, it could have been more explicit about the exact structure of the returned overview, but the enumerated categories are enough for an agent to call it correctly.

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