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

No annotations provided, so the description carries full burden. It discloses return values (uuid, resolved UVs), coordinate system (Blockbench units), and supported features (rotation, inflate). It does not mention permissions or side effects, but the behavior is clear for a non-destructive create operation.

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

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

Five front-loaded sentences with no wasted words. Each sentence adds critical context: purpose, coordinates, feature recommendations, alternative usage, and return value. Highly 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?

Despite no output schema, the description covers return values and links to painting. It mentions key optional features and provides enough context for a modeling tool. All important aspects are addressed given the tool's complexity.

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

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

Schema coverage is 91% (high), baseline 3. The description adds value by explaining coordinate units, defaults (origin to from), and usage hints for rotation and inflate. This goes beyond the schema definitions.

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 'Add a cube to the model' and distinguishes it from siblings by recommending 'add_cubes' for batch adding. It specifies the resource (cube) and the action (add), with no ambiguity.

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 guidance: prefer add_cubes for many cubes, parent to a rotated group for compound angles, and use rotation/inflate to avoid robotic flat boxes. It tells when and why to use this tool vs alternatives.

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

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

No annotations provided; description fully bears the burden. It discloses efficiency, array structure, symmetric building advice, and return value (all created cubes with face UVs), adding useful context beyond basic functionality.

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

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

Front-loaded with purpose, then adds usage tips. Slightly verbose but every sentence is informative; could be tightened.

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

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

With one parameter, no output schema, and no annotations, the description covers purpose, parameter details, usage guidance, return value, and common pitfalls thoroughly.

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% but description adds meaning by detailing that each item takes fields like add_cube, and provides guidance on symmetric parts and Z-fighting, which is beyond 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 states 'Create many cubes in one call — the efficient way to author a detailed model', clearly indicating verb (create) and resource (cubes), and distinguishes from add_cube by emphasizing bulk efficiency.

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

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

Explicitly advises aiming for 20-50+ cubes and not 6-8, and provides tips on symmetric parts and Z-fighting avoidance. Alternative add_cube is implied but not explicitly mentioned.

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

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

With no annotations, the description carries the full burden. It discloses that the tool creates an element, returns its uuid, and explains rotation behavior. However, it does not mention potential errors (e.g., invalid parent), idempotency, or permissions, leaving moderate gaps for a creation tool.

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

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

The description is front-loaded with the main action and efficiently explains key concepts in four sentences. The second sentence is somewhat lengthy but provides essential context; minor trimming could improve conciseness.

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 4 parameters, no required fields, and no output schema, the description explains creation, usage, and return value adequately. It lacks error handling details but is sufficient for an additive tool with simple semantics.

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

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

The description adds meaningful usage hints beyond the schema: for origin (set to real joint), rotation (use to pose limbs), and parent (omit for root). The name parameter lacks description in both schema and description, keeping it from a perfect score.

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 adds a group/bone to the outliner, distinguishing it from sibling tools like add_cube by explaining that groups are used for animation and multi-axis rotation. The verb-resource pair is specific and the context differentiates it well.

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 strong guidance on when to use groups (for animation and free 3-axis rotation) versus cubes (single-axis rotation) and suggests nesting groups for compound angles. However, it does not explicitly address when not to use the tool or compare to the sibling add_groups (plural).

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 groups can reference each other by name within the same call, allowing nested hierarchies. It does not mention error conditions, overwriting behavior, or limits, but since annotations are absent, the description provides the primary behavioral context for bulk creation.

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 the first sentence immediately conveying the core purpose ('Create many bones/groups in one call'). No wasted words; every part adds information.

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

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

For a tool with one parameter, no output schema, and no annotations, the description adequately covers the essential behavior: bulk creation, nesting, and parent referencing. It tells the agent how to structure the input to achieve hierarchical 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?

The schema description covers the groups parameter well, but the tool description adds the critical nuance that parent references can resolve to other groups created in the same call, which is not clear from schema alone. This adds significant 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 starts with 'Create many bones/groups in one call', clearly stating the action and object. It distinguishes from 'add_group' (singular) and mentions fast skeleton layout, differentiating from sibling tools like 'add_cubes' which handles cubes.

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 tool description implies it is for batch creation of groups, especially for building nested hierarchies. It doesn't explicitly state when not to use it or provide alternatives, but the context of 'fast way' and parent referencing provides clear guidance for its use case.

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

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

No annotations provided, so description must disclose behavioral traits. It does not mention side effects, validation errors, permissions required, or any behavior beyond adding the keyframe. For a mutation tool, this is insufficient.

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, front-loaded with key information, no extraneous words. Every part is necessary.

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

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

For a 6-parameter tool without output schema, the description is minimal. It covers the core action but lacks context about return values, batch vs. single, or error handling. Adequate but not rich.

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 (83%) and parameter descriptions are already detailed (e.g., bone uuid/name, time in seconds, value units). The description adds no new parameter info beyond what the schema provides, achieving baseline.

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

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

Description clearly states the action ('Add a single keyframe'), the resource ('keyframe'), and the context ('to an animation for a given bone and channel'). It distinguishes from the sibling 'add_keyframes' by emphasizing 'single'.

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 explicit guidance on when to use this tool versus alternatives like 'add_keyframes'. The description implies singular usage by saying 'single keyframe', but does not state when batch is preferred or provide usage context.

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

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

With no annotations, the description must disclose behavioral traits, but it only says 'Add many keyframes at once'. It does not explain whether keyframes overwrite existing ones, what happens if the animation doesn't exist, or any authorization or side effects. The mutation aspect is implied but not detailed.

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 very concise: two sentences with no wasted words. It front-loads the core purpose and then gives the data shape. Every sentence adds value.

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, no annotations, and parameters that need explanation, the description is incomplete. It lacks details on return values, error handling, prerequisites, and constraints. For a mutation tool, more context on behavior and success/failure indicators is necessary.

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

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

Schema description coverage is 0%, so the description carries responsibility. It lists the fields of the keyframe object (bone, channel, time, value, interpolation), adding some structure beyond the schema. However, it does not explain field semantics (e.g., bone refers to which bone, time units, or interpolation options), leaving the agent to infer from 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 the tool adds many keyframes at once, positioning it as the efficient batch version. It distinguishes from the sibling tool 'add_keyframe' implicitly by highlighting 'many at once' and 'author a full animation'.

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

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

The description implies use for bulk keyframe insertion when creating full animations, but does not explicitly mention when not to use it or contrast with single-keyframe alternatives like 'add_keyframe'. No exclusions or prerequisites are stated.

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

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

With no annotations, the description carries the full burden. It discloses that meshes need mesh-capable formats and warns about limitations for certain exports. It also gives parameter hints (e.g., 'For a shard make h large'). However, it does not discuss side effects or permissions.

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 sentences and a note, each sentence earning its place: first states purpose, second gives usage context, note warns limitations. No unnecessary 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?

Given the complexity (10 parameters, no output schema), the description covers purpose, examples, limitations, and parameter hints. It does not explain return values, but the overall completeness is high for agent decision-making.

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 (90%), but the description adds value beyond the schema by providing usage context (e.g., 'For a shard make h large') and explaining UV rect and segments. This enriches understanding beyond default values.

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

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

The description explicitly states it creates non-cuboid MESH primitives, listing specific shapes like crystals, pyramids, cones, etc. It clearly differentiates from sibling tools like 'add_cube' by focusing on non-axis-aligned geometry.

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

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

The description provides explicit when-to-use examples ('Great for crystal cores, blades, horns...') and a when-not-to-use note with an alternative approach for GeckoLib/Java format, where users should build crystals from rotated cubes instead.

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

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

With no annotations, the description carries full burden. It discloses the plane's nature (zero-depth cube, two-sided), the crossed option, and parenting capability. It does not contradict annotations (none present) and adds valuable behavioral context beyond the schema.

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

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

The description is two sentences, front-loaded with the primary purpose, and every sentence adds value (use cases, key parameter behavior). No extraneous text.

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 10 parameters and no output schema, the description covers purpose, key parameter usage, and common workflows (e.g., parent to bone). It does not describe return values, but for a creation tool, the output is implied. Reasonably 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 high (90%), so baseline is 3. The description adds extra meaning by explaining how crossed:true creates an X shape and suggesting pairing with VFX texture, which improves understanding 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 'Create a flat 2-sided plane (billboard)' with specific use cases (pixel VFX, thin details). It distinguishes from siblings like add_cube and add_mesh by noting it is a zero-depth cube, providing a clear verb and resource.

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 to use (VFX, thin details, volumetric look with crossed:true, parent to bone for animation). It implicitly guides usage but lacks explicit when-not-to-use or alternative tool names.

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

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

No annotations are provided, so the description carries full burden. It does not disclose whether the texture overwrites existing textures or other side effects, nor does it mention requirements like the element having faces.

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 concise sentence with front-loaded key information, no wasted words.

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

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

For a tool with two parameters and no output schema, the description covers the core functionality and optionality adequately, though missing return value or behavioral details for completeness.

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

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

Schema coverage is 0%. The description adds meaning by indicating element is optional and explaining the effect of omission, but does not describe valid values or formats for the texture parameter, partially compensating.

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 it applies a texture to all faces of an element or all cubes if element is omitted. It uses a specific verb and resource, distinguishing it from siblings like paint_faces or paint_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 provides a condition for omitting element, but does not explicitly compare with other texture-related tools such as paint_texture or paint_faces, leaving when-to-use guidance incomplete.

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

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

With no annotations provided, the description carries the full burden of transparency. It comprehensively lists the types of issues checked and states the return format ('grouped issue list'). No behavioral contradictions are 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?

The description is appropriately sized and front-loaded with the main purpose. It uses a structured list of issues. While slightly long, every sentence adds value. A minor improvement would be to further condense the parenthetical examples.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is complete. It explains what the tool detects, when to run it, what to do with results, and the return format ('grouped issue list'). No additional information is required.

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 has no parameters, so the schema coverage is effectively 100%. The description adds significant value by explaining the tool's purpose and behavior, which is more than the baseline 3 for high coverage.

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

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

The description clearly states that the tool audits the model for specific problems such as untextured faces, zero-area UVs, degenerate cubes, unparented cubes, and Z-fighting. It distinctly differentiates from sibling tools, none of which perform a similar audit.

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 clear when-to-use guidance: 'Run this after building and before/after texturing, then fix what it reports.' It also gives specific advice for fixing coplanar_overlap. However, it does not explicitly state when not to use the tool or mention alternatives, which prevents 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?

No annotations. Description only states action without detailing side effects (e.g., unsaved changes, prompts, or state changes).

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

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

Single sentence, front-loaded, no unnecessary 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?

Minimal description for a potentially impactful action. Lacks detail on save behavior, error states, or post-close status.

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

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

No parameters; schema coverage is 100% trivially. Description adds no parameter info, but none needed.

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

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

Clear verb 'close' and resource 'project' with no ambiguity. Distinct from sibling tools like new_project and load_project.

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

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

No guidance on when to use or when not to use. Does not mention prerequisites or consequences (e.g., saving before close).

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

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

No annotations are provided, so the description carries full burden. It only states the action and return value. It does not disclose side effects, potential errors, or behavioral details such as whether existing animations are modified, or if the project state needs to be saved first.

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 immediately identifies the action and key requirements. It contains no filler or redundant information, making it efficient for an AI agent to parse.

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

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

Given the tool's complexity (3 parameters, no output schema, no annotations), the description covers the primary purpose, a critical prerequisite, and the return value. It is nearly complete, though it omits context like whether a project must be open or how missing parameters are handled.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds no additional parameter-level meaning beyond what the schema provides. It does mention the return value (UUID), but this is output, not parameter semantics.

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

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

The description clearly states the tool's purpose: 'Create an animation'. It specifies the requirement for a format supporting animation and explicitly mentions the return value (UUID). This distinguishes it from sibling tools like 'remove_animation' and 'list_animations'.

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 key prerequisite: the format must support animation (e.g., GeckoLib or Bedrock entity). It gives concrete examples of compatible formats. However, it does not explicitly state when to use this tool versus alternatives, nor does it discuss what happens if the condition is not met.

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

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

No annotations are provided, so the description is the sole source of behavioral info. It states the return value (uuid) but does not disclose side effects, conflict behavior (e.g., both fill and data_url provided), idempotency, or authorization needs.

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. It front-loads the verb and resource, 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?

Given 6 parameters and no output schema or annotations, the description is too brief. It misses details on parameter interactions, defaults, and edge cases. Agent may not know how to handle conflicting inputs or what the return value contains beyond the uuid.

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 (83%), but the description adds value by clarifying the two creation paths (fill vs data_url) and that they are alternatives. It does not explain the default behavior for width/height or the particle parameter, but still enhances understanding 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 creates a texture and specifies two methods (fill color or data_url). It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like import_texture or create_vfx_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 gives no guidance on when to use this tool vs alternatives such as import_texture or apply_texture. It mentions two creation methods but does not explain when to choose one over the other.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: baking a vertical flipbook when frames>1, starting the animation player, defaulting to additive/emissive render mode and double-sided rendering. It doesn't cover all edge cases but provides sufficient 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, dense paragraph that efficiently conveys purpose, behavior, and usage. It is front-loaded with the main function and avoids unnecessary verbosity, though a more structured breakdown could improve readability slightly.

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

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

Given the tool's 14 parameters and no output schema, the description covers the core functionality: texture generation, flipbook animation, default render settings, and application to planes. It references a guide for further details, making it fairly complete for an AI agent to understand usage.

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

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

Schema description coverage is 86%, so the baseline is 3. The description adds overall context (e.g., flipbook, render modes) but does not elaborate on individual parameters beyond what the schema already provides. It does not detract, but also does not significantly enhance parameter understanding.

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 generates a pixelated VFX texture with specific visual characteristics (hot core, cool edges, quantized color bands, jagged edges). It gives concrete examples like pixel flames/energy/projectiles, distinguishing it from sibling tools that create generic textures or other elements.

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 specifies when to use it (for VFX textures on planes with optional flipbook animation) and provides usage context: apply to add_plane planes, animate with bones, and refer to a guide for more details. It lacks explicit when-not-to-use instructions but offers clear context.

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

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

The description discloses that deleting a group deletes its children, which adds behavioral info beyond a simple 'delete element'. However, it does not mention if deletion is reversible or if it requires specific permissions, especially given no 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, concise sentence that conveys the core functionality without any extraneous words. It is well-structured and 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?

Given the simplicity of the tool (one parameter, no output schema), the description covers the basic functionality. However, it lacks mention of destructive nature or confirmations, which would be helpful for a delete operation.

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

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

The schema has 100% description coverage for the single parameter 'element', already stating 'uuid or name.'. The tool description adds no additional meaning to the parameter beyond what is 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 clearly states it deletes a cube or group along with its children, using specific verb 'Delete' and resource types 'cube' or 'group'. It distinguishes from sibling tools like add_cube or edit_element.

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

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

No guidance on when to use this tool vs alternatives (e.g., hide, edit). No context on prerequisites or consequences compared to sibling tools like remove_animation or edit_element.

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

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

With no annotations, the description carries full burden. It describes exactly what happens: texture assignment, gradient baking, directional shading, mottle, blur, and emissive handling. It does not state side effects like reversibility, but the mutative behavior is clear.

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?

Description is relatively concise, covering purpose, workflow, and key features in a few sentences. It is front-loaded with the primary intent. No fluff, every sentence adds value.

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 optional parameters and no output schema, the description thoroughly explains what the tool achieves, the pipeline context, and special behavior for emissive cubes. It compensates for missing annotations with rich detail, making the tool fully understandable.

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

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

Schema coverage is 100%, so baseline 3. The description adds workflow context but does not significantly augment per-parameter meaning beyond the schema's own descriptions. The emissive regex mention reinforces schema but doesn't add new insight.

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 SMOOTH base texturing, assigning texture to chosen faces with specific shading and blur. It distinguishes from siblings like pack_uv, create_texture, and paint_faces by detailing its specific role in the workflow.

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

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

Provides explicit workflow order: 'Run pack_uv FIRST, then this right after create_texture, then paint_faces'. It also notes when the tool avoids dirty/grid look, implying use case. Downside: no explicit 'when not to use' but contextual enough.

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

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

No annotations exist, so the description must disclose behavior. It lists actions but omits details like destructiveness, error conditions, or whether multiple edits can be applied at once.

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 efficient sentence, front-loaded with main action and examples, 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 complex tool with 9 optional parameters and no output schema, the description lacks details on return values, success indicators, and error cases, leaving 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 moderate (67%). The description lists edit actions that loosely map to parameters but does not explicitly connect them, adding 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?

The description clearly states the tool edits existing cubes or groups and lists specific actions (rename, move, rotate, etc.), which differentiates it from siblings like add_cube or delete_element.

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

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

No guidance on when to use this tool versus alternatives (e.g., delete_element for removal, add_cube for creation), nor 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?

With no annotations, the description fully shoulders the burden. It discloses that the code has access to all Blockbench globals, receives a `params` object, and must return JSON-serializable values. It also provides a critical usage hint about wrapping edits. It does not mention error handling or security, but is otherwise transparent.

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 adding crucial information: purpose, capabilities, and usage warning. It is front-loaded with the primary action and avoids 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 the tool's complexity (arbitrary script execution), the description covers the key aspects: what it runs, environment, input, output, and fallback nature. It omits details like error behavior or performance, but is complete enough for an agent to decide appropriately.

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% for both parameters. The description adds value beyond the schema by providing usage tips for the 'code' parameter (e.g., wrap edits in Undo.initEdit/finishEdit) and clarifying that 'params' is optional and passed as an object.

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 executes arbitrary JavaScript inside Blockbench's renderer for anything not covered by dedicated tools. It specifies the verb 'run', resource 'arbitrary JavaScript', and distinguishes from siblings by framing it as a fallback.

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 sparingly; prefer dedicated tools', providing clear when-to-use and when-not-to-use guidance. It also implies it's for edge cases not handled by other tools.

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

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

With no annotations, the description carries full burden. It states writing to a file if path is provided but omits behavior without path (e.g., returning data). It does not disclose potential side effects (e.g., no modification) or failure modes.

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

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

The description is concise at two sentences with no wasted words. It is front-loaded with the main action. Minor improvement possible by merging path explanation into the first 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?

Given no output schema and one optional param, the description is incomplete. It does not explain the return value when path is omitted, nor does it list supported formats beyond examples. An agent may miss critical usage details.

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

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

The description adds meaning to the 'path' parameter by explaining it writes a file directly, which the schema does not. However, it does not clarify what happens when omitted, and schema coverage is 100%, so the description provides only marginal extra value.

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 identifies the action (export) and resource (project), with examples of output formats. It distinguishes from sibling tools like save_project by specifying 'through its format's codec'. However, it lacks precision on what happens when 'path' is omitted.

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 examples of formats but no explicit guidance on when to use this tool versus alternatives (e.g., save_project for native format). It does not mention prerequisites or context like needing an open project.

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

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

No annotations provided, and description only states 'Get detailed info', missing disclosure of read-only nature, error handling, or auth needs.

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, front-loaded with key information, no unnecessary 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?

Adequate for a simple get tool, but lacks detail on what 'detailed info' includes and no output schema; could be more 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?

With 0% schema coverage, description adds meaning by explaining that 'element' can be a uuid or name, aiding usage beyond 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?

Description clearly states the verb 'Get' and resource 'detailed info for one cube or group', and distinguishes from siblings like detail_cubes by specifying 'one'.

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?

Description implies use when needing info on a single element, but no explicit guidance on when not to use or alternatives like detail_cubes for multiple elements.

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

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

No annotations are provided, so the description carries full burden. It only describes the return value and topic meanings, but does not disclose any behavioral traits such as side effects, authentication needs, or rate limits. More detail would be beneficial.

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 front-loads the purpose and then enumerates topics with parenthetical details. It is efficient while being sufficiently informative.

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 tool with one optional parameter and no output schema, the description covers all necessary context: what it returns, the available topics, and when to use it. No obvious gaps remain.

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

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

The input schema has 100% coverage with enum descriptions, but the description adds substantial context for each topic (e.g., 'proportions, detail, rotation' for modeling). This goes beyond the schema's brief descriptions, enhancing meaning.

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

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

The description clearly states 'Return a playbook' with specific verbs and resources. It distinguishes among five discrete topics with detailed explanations, making it unambiguous from 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?

The description explicitly advises reading the relevant topic before building/texturing/animating, providing clear usage context. While it doesn't specify when not to use it, the guidance is strong enough for a simple reference tool.

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

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

No annotations provided, so description must carry behavioral disclosure. It correctly indicates a read operation (Get) with no destructive actions. However, it doesn't mention prerequisites (e.g., needing an open project) or any side effects, rate limits, or authorization needs. Adequate for a simple state retrieval but lacks full transparency.

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

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

Two sentences: first states purpose with specific outputs, second provides usage guidance. No extraneous information; 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?

Given zero parameters and no output schema, the description covers key aspects: what the tool returns and when to use it. Could mention error conditions or return format but is sufficiently complete for a simple getter.

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?

No parameters exist (schema coverage 100% for empty schema). Baseline for 0 params is 4. Description adds value by explaining what the tool returns (state components), which is meaningful 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?

Description clearly states verb 'Get' and resource 'current Blockbench state', listing specific components (open project, format, counts of cubes/groups/textures/animations, edit mode). It distinguishes from siblings by advising to call get_status first and to use get_guide before building/texturing.

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

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

Explicitly recommends calling this first to understand the workspace and provides a conditional alternative: use get_guide before building or texturing. Could more broadly state when not to use, but the guidance is clear and context-aware.

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

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

No annotations are provided, so the description carries the full burden. It mentions reading and returning PNG inline but does not disclose any potential side effects, permission requirements, or rate limits. The read-only nature is implied but not explicit.

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 consists of two concise sentences that communicate the core functionality and output format without unnecessary words. It is well 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 simple single-parameter tool with no output schema, the description is nearly complete. It explains what the tool does and what it returns (PNG inline). Minor gap: it doesn't clarify if the texture must be loaded or any prerequisites.

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

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

Schema description coverage is 100% for the single parameter, with a clear description 'uuid or name.' The tool description adds no additional meaning beyond what the schema already provides, 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 clearly states the verb ('read'), resource ('texture'), and purpose ('inspect what it currently looks like'). It distinguishes from sibling tools like import_texture or create_texture by indicating a read-only inspection operation.

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 inspection but does not explicitly state when to use it versus alternatives or provide when-not conditions. Some guidance is implied through the purpose, but no explicit exclusions are given.

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

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

No annotations are provided, so the description should disclose behavioral details. It only mentions 'desktop only' and imports from disk, but omits whether it overwrites existing textures, what file formats are supported, or error handling 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 description is a single, front-loaded sentence with no filler. Every word adds value, specifying the action, resource, source, and platform restriction.

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 import tool with two parameters and no output schema, the description covers the basic purpose but lacks details on parameter behavior and return values. It is adequate but not thorough.

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

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

With 0% schema description coverage, the description must explain parameters. It only implies the 'path' parameter for the file location but does not describe the optional 'name' parameter or any expected formats. This is insufficient.

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 imports a texture from an image file on disk, with the restriction 'desktop only'. This distinguishes it from siblings like create_texture (procedural) and apply_texture (application).

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 when a texture file exists on disk, and includes a platform restriction. However, it lacks explicit guidance on when to prefer this over create_texture or when not to use it (e.g., for procedural textures).

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

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

No annotations provided, so description must cover behavior. It mentions installation necessity but fails to disclose side effects (e.g., overwrite behavior), permissions (e.g., network access for store/url), or idempotency. Agent lacks details on what happens if plugin already installed or if dependencies are required.

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 wasted words. First sentence covers all parameters and methods; second provides usage context. 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?

With no output schema, description should explain outcomes. It mentions pre-condition (needed before using plugin formats) but not post-condition or return value. Adequate for a simple installer but lacks return info or error handling hints.

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%, baseline 3. Description adds value by explaining that 'id' is a store plugin id with example, 'url' is direct https to .js, and 'path' is local file path. Clarifies alternative methods beyond schema's generic 'Store plugin id.' 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?

Explicitly states the action (install), the resource (plugin), and the three methods (id, url, path). Distinguishes from sibling tools like uninstall_plugin and list_plugins.

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

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

Provides clear context: 'Needed before using plugin-specific formats like GeckoLib's geckolib_model.' Does not explicitly exclude cases or mention alternatives, but the trigger scenario is well-defined.

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

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

With no annotations, the description carries full burden. It indicates a read operation by listing, but does not disclose any side effects, authentication needs, or performance characteristics. It is minimally sufficient but lacks depth.

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 with no extraneous words, front-loading the action and resource. It is optimally concise.

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

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

Given no output schema, the description could explain the return format more thoroughly (e.g., data structure of animations and bones). However, it conveys the core functionality adequately for a simple list tool.

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

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

The tool has zero parameters and 100% schema coverage, so the baseline is 4. The description adds no parameter info since none exist, which 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 verb 'List' and the resource 'animations', and specifies 'their animated bones', making the tool's function distinct from sibling tools like create_animation or remove_animation.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or contexts where it should or should not be used.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool lists formats from the install including plugins, implying a read-only, non-destructive operation. It does not discuss auth or rate limits, but the behavior is straightforward.

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

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

Two sentences, front-loaded with the action and examples, no wasted words. Efficient and easy to parse.

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

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

The description covers the tool's purpose and usage hint. It does not describe the return format explicitly, but the mention of 'returned `id`' implies a structure. Without an output schema, this is acceptable for a simple list.

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 has zero parameters, so the schema covers everything. The description adds no parameter details but none are needed. Baseline score of 4 applies for no 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 the verb 'List' and the resource 'model formats', provides concrete examples (free, java_block, bedrock, plugin-added), and distinguishes it from sibling tools by listing formats, which no other 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 explicitly tells the agent to use the returned id with new_project, indicating the tool's role in project preparation. It lacks explicit when-not-to-use or alternatives, but the context is clear given no sibling tools perform this function.

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?

Without annotations, the description implies a read-only operation by specifying it returns data, but does not disclose potential performance impact or scope (e.g., current project only). Adequate but not thorough.

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, clear sentence that efficiently conveys the tool's purpose and output without extraneous words.

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

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

For a no-parameter tool with no output schema, the description could be more precise about the return format (e.g., nested structure vs flat list), but it suffices for basic understanding.

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 has no parameters, so the schema coverage is 100% by default. The description adds no parameter detail, but this is acceptable as there are none to describe.

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 returns the full outliner tree with specific attributes (uuids, origins, rotations), distinguishing it from sibling tools that perform different operations.

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

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

No guidance is provided on when to use this tool versus alternatives like get_element or detail_cubes, nor any prerequisites or context for invocation.

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

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

No annotations are provided, and the description does not disclose behavioral traits like read-only nature, permissions, or side effects. It assumes the tool is a safe listing operation but fails to confirm this, leaving the agent with incomplete information.

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 concisely captures the tool's function and key usage. Every word serves a purpose, with no unnecessary elaboration.

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 list tool with two parameters and no output schema, the description adequately covers the functionality. It could mention the return type is a list of plugins, but this is implicit and not a critical gap.

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

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

With 50% schema description coverage, the description adds value by mentioning both parameters as filters. However, it does not fully explain the boolean 'installed_only' parameter, leaving ambiguity about its exact meaning (e.g., whether it shows only installed or only store plugins).

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 lists Blockbench plugins, both installed and from the store, with filtering options. It uses specific verb 'list' and resource 'plugins', distinguishing it from action-oriented siblings like install_plugin or uninstall_plugin.

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 clear context for when to use the tool: when listing plugins with optional filtering. It does not explicitly mention when not to use it or alternatives, but the purpose is well-defined and the filtering guidance is helpful.

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

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

No annotations provided, and the description does not disclose behavioral traits like read-only nature, return format, or whether it requires any context. The description is too minimal to inform the agent of important behaviors.

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?

Extremely concise one-sentence description with no filler. Front-loaded purpose.

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 list tool with no parameters and no output schema, the description is minimally complete. However, it lacks details about what information is returned or any limitations, making it less helpful.

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?

No parameters exist, so schema coverage is 100%. The description adds no param info, but none is needed. 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 clearly states the verb 'list' and the resource 'textures' (all textures). It distinguishes from sibling listing tools like list_animations by specifying the exact resource.

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 explicit guidance on when to use vs alternatives (e.g., get_texture for a single texture). The use case is implied but not elaborated.

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

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

With no annotations provided, the description must fully disclose behavior. It states the tool loads a file, but does not mention potential side effects (e.g., closing the current project, handling nonexistent files, or clearing unsaved changes). This is adequate for a simple load operation but lacks depth.

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 of 11 words, containing no redundant information. It front-loads the critical information (verb and resource) and is perfectly concise.

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

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

For a low-complexity tool with one parameter, the description covers the core purpose and a key constraint (desktop only). It does not address error conditions or behavior when the file is missing, but given the simplicity, it is reasonably 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 input schema already describes the sole parameter 'path' as 'Absolute path to a .bbmodel file.' Since schema coverage is 100%, the description adds no additional semantic information beyond the schema. The 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 verb 'Load', the resource '.bbmodel project file', and the context 'from disk (desktop only)'. This distinguishes it from sibling tools like new_project or close_project, making its purpose unmistakable.

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

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

The description gives clear context by specifying 'from disk (desktop only)', which implies it is for loading an existing local file. However, it does not explicitly mention when not to use it (e.g., if the file is already open) or point to alternatives like import_texture. Still, the context is sufficient for basic selection.

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

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

With no annotations, the description carries full burden. It discloses key effects (flips geometry, renames left/right, returns clones) but is ambiguous whether the original is modified or preserved. Missing details on destructive behavior or permissions.

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: action context, behavioral effects, return value. Front-loaded and 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?

Given 4 parameters with full schema coverage and no output schema, the description covers core functionality and return. Missing edge cases like error handling or prerequisites, but adequate for typical 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 coverage is 100%, so baseline is 3. Description adds minimal extra meaning beyond schema (e.g., 'axis about a pivot' matches parameters). Does not explain distinction between 'element' and 'elements'.

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 'Mirror a cube or group across an axis about a pivot' with specific behavioral details (flips geometry, rotation signs, renames left/right). It differentiates from sibling tools by focusing on mirroring for symmetric modeling.

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

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

Provides context 'build one side of a symmetric model, then mirror it', implying when to use. Does not explicitly exclude alternatives or name them, but the usage scenario is clear and sufficient.

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

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

No annotations are provided, so the description carries the full burden. It only mentions 'from the start screen' and 'choosing a format', but omits details about side effects (e.g., closing current project), prerequisites, or error conditions. Minimal behavioral disclosure.

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

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

Two sentences with no wasted words. Front-loaded with key action 'Create a new project'. Extremely concise.

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

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

The description is adequate for a simple creation tool, but it omits details like that the new project becomes the active project, or how it interacts with other tools (e.g., save_project). Could be more complete given the lack of output schema and annotations.

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

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

Schema description coverage is 100%, with each parameter documented in the input schema. The description adds no additional meaning 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 description clearly states the tool creates a new project from the start screen, choosing a format, and identifies it as the entry point for any new model. This distinguishes it from siblings like 'load_project' or 'export_project'.

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 that this tool is used when starting a new model, but it does not explicitly state when not to use it or mention alternatives like 'load_project'. The guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It discloses auto-grows texture preserving paint and that all cubes get their own region. However, it does not explain what happens to existing UVs or specify any destructive behavior (e.g., overwriting UVs).

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, each earning its place: action, required context, and auto-resize behavior. No unnecessary words, front-loaded with the key purpose.

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

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

Given the tool's complexity (3 simple parameters, no output schema), the description is fairly complete. It explains why the tool is needed and when to re-run. A minor gap is lack of detail on how padding affects layout or what 'all' means for cubes parameter.

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

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

Schema description coverage is 100%, so the schema already documents the parameters. The description adds minimal extra meaning beyond the schema; for example, it does not clarify the format of cube names or the effect of padding.

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 ('Shelf-pack the box UVs') and the specific resource ('box UVs for a box_uv model'). It distinguishes itself from siblings like set_cube_uv by indicating it packs all cubes into their own region, which is a distinct operation.

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 'REQUIRED before texturing' and 'Re-run after adding or resizing cubes', providing clear when-to-use guidance. However, it does not mention when not to use or compare with alternative tools like set_cube_uv for individual adjustments.

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

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

No annotations are provided, so the description carries full burden. It discloses the relative coordinate system and batch form. However, it does not mention whether painting overwrites existing data, if it requires existing textures, or any error cases. More behavioral details would improve transparency.

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

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

The description is two sentences: the first states the core functionality and key benefit (no UV math), the second provides use cases and usage forms. It is front-loaded with the most critical info and contains no redundant phrases. Every sentence adds value.

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

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

Given the tool's complexity (6 parameters, no required, no output schema), the description covers the coordinate system, batch form, and use cases. It lacks information about return values or error handling, but for a painting tool, the essential usage is well explained.

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 baseline is 3. The main description adds context about relative coordinates and batch vs single forms, but these details are also present in the schema descriptions. The description does not significantly enhance parameter understanding 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 clearly states the tool paints features onto cube faces using relative coordinates, avoiding UV math. It distinguishes itself from sibling tools like 'paint_texture' and 'set_cube_uv' by focusing on face-specific painting. The mention of use cases (eyes, nostrils, etc.) provides concrete examples.

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 lists use cases (eyes, nostrils, etc.) and implies it is for face-level painting rather than whole textures. However, it does not explicitly name alternative tools or state when not to use this tool. The context from sibling tools suggests alternatives like 'paint_texture' but the description lacks direct 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?

The description discloses the coordinate system and execution order, which is helpful. However, without annotations, it does not explicitly state that the texture is modified in place or discuss undo behavior, though edit_name hints at it. Leaves a small gap in full transparency.

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

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

The description is three sentences, each contributing essential information: purpose, usage guidance, and coordinate system. No redundancy 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?

Given the tool's complexity (multiple op types), the description covers the main aspects. However, it does not explicitly state the outcome (e.g., texture is updated) or mention error conditions. Minor lack of 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 description adds significant value beyond the schema by listing all operation types and their parameters with examples. Schema coverage is 100%, but the description enriches understanding of the ops array structure.

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 (paint), resource (texture), and coordinate system (absolute pixel coordinates). It also distinguishes from the sibling tool paint_faces by noting the coordinate difference.

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 (whole-sheet work) and when to use the alternative (paint_faces for face-relative coordinates). It also mentions that ops run in order, providing clear context for usage.

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 traits such as whether deletion is irreversible, if the resource is freed, or any side effects. With no annotations present, the description carries the full burden and fails utterly.

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 very concise (5 words), but it is under-specified. It earns its place but does not provide sufficient structure or detail. It is front-loaded but lacks any supporting information.

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

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

For a simple tool with one parameter and no output schema, the description is incomplete. It fails to explain how to identify the animation or what happens after deletion. Minimal completeness is not achieved.

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 parameter 'animation' has no description in the schema (0% coverage), and the tool description adds no meaning beyond its name. The agent receives no information on what constitutes a valid animation identifier.

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

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

The description explicitly states the verb 'Delete' and the resource 'animation', making the tool's purpose clear. It distinguishes from siblings like 'create_animation' and 'add_keyframe'.

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 provided on when to use this tool versus alternatives or what prerequisites are needed. The description lacks any contextual usage advice.

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

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

No annotations provided, and description lacks details about side effects (e.g., overwriting original texture), resolution limits, or error behavior. Only mentions resampling method.

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 that is front-loaded with the verb. No unnecessary words, but could include more detail without becoming verbose.

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

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

With no output schema and 0% parameter coverage, the description is too minimal. Missing return value or confirmation of success. Not complete for an AI agent.

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

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

Schema coverage is 0%, meaning no parameter descriptions in the schema. Description does not explain 'width', 'height' units, or what the 'texture' string refers to (ID, path?). Fails to compensate for 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?

Description clearly states the action (resize), resource (texture's bitmap), and method (nearest-neighbour). It distinguishes from sibling tools like create_texture or apply_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?

No guidance on when to use this tool versus alternatives like create_texture or import_texture. No exclusions or prerequisites mentioned.

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

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

No annotations are provided, so the description bears full responsibility. It discloses the basic save behavior but does not mention potential side effects like overwriting existing files, required permissions, or whether a project must be open. The description lacks detail on error conditions or confirmation dialogs.

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, consisting of two short sentences that front-load the main action and then explain the parameter behavior. Every sentence serves a purpose 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?

Considering the tool's simplicity and the presence of sibling tools, the description covers the essential functionality. However, it does not mention return values or success/failure indications, which would be helpful given the lack 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?

The input schema has 100% coverage for the 'path' parameter. The description adds value by explaining the optional nature and the consequence of providing or omitting it (desktop save vs. default flow), which goes beyond the 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 clearly states the action ('save'), the resource ('open project'), and the file format ('.bbmodel'). It distinguishes itself from sibling tools like 'load_project' and 'export_project' by specifying the save operation.

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 guidance on when to use the tool and explains the behavior of the optional 'path' parameter: provide a path to save to a specific file, otherwise use Blockbench's default save flow. It does not explicitly mention alternative tools for related tasks, but the context is clear.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions optional width/height but does not specify image format, return details, or state that the action is non-destructive. While the tool's behavior is largely obvious from its purpose, the description could be more explicit.

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 wasted words. The first sentence covers purpose, the second adds parameter info. It is efficient but could be slightly more structured (e.g., bullet points or clearer separation of purpose and 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?

For a simple tool with 2 optional parameters and no output schema or annotations, the description covers the basic purpose and parameter optionality. However, it lacks details on return format, real-time behavior, or edge cases, which would be helpful for an agent.

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

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

Schema description coverage is 0%, so the description must compensate. It states 'Optionally specify width/height', which clarifies that parameters are optional and control dimensions, but it does not provide units, default values, or range constraints. This adds minimal meaning beyond the schema's property 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 the verb 'capture', the resource 'current 3D preview', and the purpose 'so you can visually inspect the model and iterate'. It distinguishes from sibling 'screenshot_views' by specifying the current 3D preview.

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 for visual inspection but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like screenshot_views. It is adequate but lacks clear context.

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

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

No annotations are provided, so the description must disclose behavioral traits. It mentions returning images but does not specify format, side effects (e.g., file creation), or limitations. For a tool that captures screenshots, missing details like output type or resolution behavior reduce transparency.

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

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

The description is four sentences with minimal wasted words. It front-loads the main action and adds usage guidance efficiently. Could be slightly more structured but is concise overall.

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

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

No output schema exists, so the description should explain return values (e.g., image format, encoding). It only says 'return them as images'. Missing details like number of images, coordinate system, or error handling. For a tool with moderate complexity, this is 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?

Schema coverage is 33%—only the 'views' parameter has a description. The tool description adds context for 'views' (defaults) but provides no info for 'width' and 'height', leaving those parameters undocumented. With low coverage, more compensation is needed.

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

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

The description clearly states the action ('capture several camera angles... and return them as images') and the resource (model views). It distinguishes from the sibling 'screenshot' tool by emphasizing multiple views in one call, making 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 provides explicit usage guidance: 'This is the main way to review and iterate — do it after each modeling/texturing pass, not just once.' It also mentions default views. It does not explicitly exclude alternatives but the context strongly implies when to use.

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

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

No annotations are provided, so the description must disclose behavior. It states the action but does not specify side effects, permissions, or behavior when both preset and explicit parameters are supplied. Basic transparency but lacking depth.

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 that is front-loaded with the main action and efficiently covers the key usage options. 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?

With 4 parameters fully described in the schema and no output schema, the description focuses on the primary purpose. It omits mention of the 'angle' parameter for orthographic projection, which is documented in the schema, so overall completeness is adequate but could be slightly richer.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that the tool accepts 'named preset and/or explicit' parameters, hinting at the relationship between preset and position/target, which the schema does not explicitly state.

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 'Position' and resource 'the preview camera', with explicit methods: 'by named preset and/or explicit camera position & target'. It distinguishes itself from sibling tools as the only camera positioning 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?

No explicit when/when-not guidance is given, but since there are no alternative camera tools among siblings, the description implicitly defines its usage context.

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

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

No annotations are provided, so the description must fully convey behavioral traits. It discloses that the tool modifies UV mapping and texture but omits details about whether it overwrites existing values, requires existing cube, or has side effects. For a mutation tool without annotations, this is insufficient.

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, concise sentence that front-loads the verb and resource. It contains no filler and every word is meaningful.

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 nested parameters, the description is minimal. It states what the tool does but not how it behaves (e.g., overwrite behavior, error conditions). Adequate for a simple tool but lacks completeness for safe agent 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 input schema has 100% coverage, describing both parameters in detail, including the nested structure for faces. The description echoes 'per-face texture' but adds no new meaning beyond the schema. 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 clearly states the tool sets UV mapping and/or per-face texture on a cube's faces. It uses a specific verb 'set' and specific resources 'UV mapping' and 'per-face texture', distinguishing it from sibling tools like 'paint_faces' or 'pack_uv' which handle different texture operations.

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

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

The description implies when to use (when needing to set UV mapping or per-face texture on a cube) but provides no explicit guidance on when not to use it or alternatives. Sibling tools like 'paint_faces' or 'pack_uv' are not mentioned, leaving the agent to infer context.

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

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

No annotations are provided, so the description bears full responsibility. It only indicates a mutation ('update') but fails to disclose side effects, error conditions, default behaviors, or return values. For a mutation tool, this is insufficient.

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 concise sentence that quickly conveys the tool's purpose. It is front-loaded with the key action. However, it could be slightly improved by listing parameters more explicitly for clarity.

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

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

Given the tool has 4 parameters, no output schema, and no annotations, the description is too brief. It lacks context on parameter interactions, default behavior when omitting parameters, potential errors, and expected outcomes. A more comprehensive description is needed for reliable agent 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?

With 0% schema description coverage, the description must compensate. It names the parameters at a high level (name, geometry name, texture resolution), which adds context beyond the schema names. However, it doesn't explain units, optionality, or constraints for texture_width and texture_height, nor the exact meaning of geometry_name.

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

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

The description clearly states the action (update) and the resource (open project's meta: name, geometry name, texture resolution). It distinguishes well from sibling tools which focus on adding, deleting, or exporting. However, it could be more precise about what 'geometry name' and 'texture resolution' entail.

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

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

No guidance on when to use this tool vs alternatives, when not to use it, or prerequisites. The description simply states what it does, leaving the agent to infer usage context without explicit cues.

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

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

No annotations are provided, so the description carries full burden. It explains the effect of each render_mode and render_sides option, but does not disclose side effects, permissions, or error states.

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 front-loads the purpose, then provides mode details and a usage tip. Every part adds value without 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?

With 8 parameters, no output schema, and no annotations, the description covers the main purpose and key parameters but omits details on frame_order_type, frame_interpolate, and animate beyond a brief mention. It is somewhat incomplete for a 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 low (38%), and the description adds meaning for render_mode and render_sides with detailed examples. However, it only vaguely mentions 'flipbook frame timing' and 'particle flag', leaving parameters like frame_order_type and frame_interpolate unexplained.

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

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

The description clearly states the verb 'set' and the resource 'how a texture renders', listing specific modes and sides. It distinguishes from siblings like apply_texture or create_texture, which do different things.

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 use cases: 'make VFX glow' and 'show planes from both sides'. It does not mention when not to use or alternatives, 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?

Without annotations, the description fails to disclose side effects (e.g., what happens to dependencies), reversibility, permissions needed, or error conditions for this destructive action.

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, concise sentence that is front-loaded with the core purpose. However, it could include more useful context without becoming verbose.

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 uninstall tool with no output schema and no behavioral details, the description is insufficient. An agent would lack information on failure modes or required state (e.g., plugin must be installed).

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

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

Schema description coverage is 0%, and the description only adds 'by id', which is vague. It does not specify the format or source of the plugin identifier (e.g., name vs UUID).

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 'Uninstall' and the resource 'installed Blockbench plugin by id', making the tool's purpose unambiguous. It effectively distinguishes from siblings like 'install_plugin' and 'list_plugins'.

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 when removing an installed plugin, but lacks explicit guidance on when to use versus alternatives or any prerequisites.

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