ClaudeKit Blender MCP

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

The description adds valuable behavioral context beyond annotations: it explains that 'Objects in Blender can belong to multiple collections' (important context), mentions 'flexible asset organization and scene management' (use case), and provides performance information ('Instant operation, negligible performance impact'). While annotations cover safety (non-destructive, idempotent), the description enriches understanding of the tool's behavior in the Blender 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 well-structured with clear sections (purpose, args, returns, examples, usage guidelines, performance) and every sentence adds value. It's front-loaded with the core functionality, followed by supporting details, with no redundant or wasted 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?

For a tool with 3 parameters, good annotation coverage (idempotent, non-destructive), and no output schema, the description provides comprehensive context: clear purpose, parameter guidance, usage boundaries, performance characteristics, and practical examples. It addresses what the tool does, when to use it, and what to expect, making it complete 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?

With 67% schema description coverage (2 of 3 parameters have descriptions), the description adds meaningful context: it explains the boolean parameter's effect ('Remove from other collections') and provides concrete examples showing how parameters interact in different scenarios. The examples illustrate the practical implications of parameter choices beyond what the schema provides.

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

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

The description clearly states the specific action ('Move or copy an object to a specific collection') and resource ('object', 'collection'), distinguishing it from sibling tools like 'blender_create_collection' (creation) and 'blender_delete_object' (deletion). The opening sentence provides immediate clarity about the tool's function.

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 includes explicit 'Use when' and 'Don't use when' sections with concrete examples ('Organizing scene assets', 'Creating new objects'), plus named alternatives ('use object creation tools instead'). This provides clear guidance on when to select this tool versus other options.

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

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

The description adds valuable context beyond annotations: it specifies that the object must exist and material must be created first (prerequisites), and mentions it assigns to the 'active material slot' (specific behavior). Annotations cover idempotency (idempotentHint: true) and non-destructive nature (destructiveHint: false), but the description complements this with practical constraints. No contradiction with annotations exists.

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

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

The description is well-structured with clear sections: purpose statement, prerequisites, parameters, return value, and usage guidelines. It's front-loaded with the core action. Minor redundancy exists (parameter info is in both schema and description), but overall it's efficient and 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?

For a tool with 2 parameters, 100% schema coverage, and annotations covering key behavioral traits (idempotent, non-destructive), the description provides complete context. It includes prerequisites, specific slot behavior, return confirmation, and clear usage guidelines. No output schema is needed as the return is simple ('Success confirmation'), and the description adequately covers the tool's role in the workflow.

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 both parameters ('object_name', 'material_name') documented in the schema. The description repeats these parameter names and purposes in the 'Args' section but doesn't add significant semantic details beyond what the schema already provides (e.g., format constraints like pattern '^[a-zA-Z0-9_]+$' for object_name are only in schema). Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the specific action ('Apply existing material to Blender object') and resource ('object's active material slot'). It distinguishes this tool from siblings like 'blender_create_material' (which creates materials) and 'blender_set_material_property' (which modifies material properties rather than applying materials to objects). The verb 'apply' and target 'object's active material slot' are precise.

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 with 'Use when: Texturing objects after creating materials' and 'Don't use when: Material doesn't exist (create it first)'. It clearly indicates the prerequisite (material must exist) and references the sibling tool 'blender_create_material' as an alternative for when materials don't exist, making it easy for an agent to choose correctly.

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

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

The description adds valuable behavioral context beyond annotations: it explains that collections can be nested hierarchically, mentions performance characteristics ('Instant operation, negligible performance impact'), and provides practical examples. While annotations cover idempotency and safety, the description enriches understanding with real-world usage patterns.

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?

Well-structured with clear sections (purpose, explanation, Args, Returns, Examples, usage guidelines, performance). While slightly longer than minimal, each section adds value. The front-loaded purpose statement is clear, and subsequent information is organized logically without redundancy.

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

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

Given the tool's moderate complexity (2 parameters, no output schema), the description provides comprehensive context: purpose, usage guidelines, parameter examples, return information, and performance characteristics. It compensates well for the lack of output schema by describing what to expect ('Collection creation confirmation and collection information').

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 100% schema description coverage, the schema already documents both parameters thoroughly. The description's Args section repeats schema information without adding significant semantic context. The examples provide some usage context but don't enhance parameter understanding beyond what's in the structured 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 new Blender collection for organizing assets, specifying both the verb ('create') and resource ('Blender collection'). It distinguishes from siblings like blender_add_to_collection (adds existing objects) and blender_list_collections (reads collections).

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

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

Explicit 'Use when' and 'Don't use when' sections provide clear guidance on when to select this tool versus alternatives. It specifies appropriate contexts (organizing scene assets, creating libraries) and when to avoid (single objects without organization needs), helping the agent make correct decisions.

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

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

Annotations already provide idempotentHint=true and destructiveHint=false, but the description adds valuable context: 'Performance: Instant operation, negligible performance impact' and 'Security: Only creates directories within project boundary.' These disclosures about speed and security boundaries go beyond what annotations provide, though it doesn't mention error conditions 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 well-structured with clear sections (purpose, args, returns, examples, usage guidance, performance, security). Every sentence adds value without redundancy, and key information is front-loaded in 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?

For a directory creation tool with good annotations (idempotent, non-destructive) and no output schema, the description provides comprehensive context: purpose, parameters, examples, usage guidelines, performance, and security. It doesn't explain return values in detail, but given the annotations and straightforward operation, this 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?

Schema description coverage is 100%, so the schema already documents both parameters fully. The description provides examples showing how directory_path is used (e.g., 'assets/models'), which adds some practical context, but doesn't explain parameter interactions or edge cases beyond what's 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 the tool creates a new directory within the Blender project structure, specifying the exact resource (directory) and action (create). It distinguishes from sibling tools like 'blender_save_file' by focusing on directory creation rather than file 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 explicitly provides 'Use when' scenarios (setting up project structure, organizing assets, creating workflow folders) and 'Don't use when' guidance (creating files, with alternative 'save_file' named). This gives clear context for when to select this tool versus alternatives.

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

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

Annotations indicate this is a non-read-only, non-destructive, non-idempotent operation (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds context by specifying it creates materials with 'standard PBR properties' and uses a specific shader workflow, which helps the agent understand the tool's behavior beyond the annotations. No contradiction with annotations exists.

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

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

The description is well-structured with a clear purpose statement, parameter list, return note, and example. It's appropriately sized for a tool with 6 parameters. Minor improvements could include integrating the example more seamlessly, but overall it's efficient with no wasted sentences.

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

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

Given the tool's moderate complexity (6 parameters, 1 required), 100% schema coverage, and annotations covering key behavioral hints, the description is mostly complete. It explains the purpose, lists parameters with defaults, and provides an example. The main gap is the lack of output schema, but the description notes 'Returns: Success message', which partially compensates.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by listing parameters with brief notes (e.g., 'RGBA [r, g, b, a] with 0-1 values', 'default 0'), but doesn't provide significant additional semantics beyond what's in the schema. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Create PBR material with Principled BSDF shader') and resource ('material'), distinguishing it from sibling tools like blender_set_material_property (modifies existing) or blender_apply_material (applies to objects). It specifies the exact shader type and workflow, making the purpose unambiguous.

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

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

The description implies usage through the mention of 'Principled BSDF workflow' and the example, suggesting it's for creating new materials with standard properties. However, it doesn't explicitly state when to use this vs alternatives like blender_set_material_property for modifying existing materials or blender_apply_material for assigning materials to objects.

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

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

The annotations already indicate this is a non-destructive, non-idempotent write operation (readOnlyHint=false, destructiveHint=false). The description adds useful context about what gets created (mesh primitive) and the default behavior (auto-generated name, default location/scale), though it doesn't mention rate limits or specific authentication needs. It doesn't contradict annotations.

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

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

The description is well-structured with clear sections (purpose, args, returns, examples, usage guidelines), front-loading the core purpose. Every sentence adds value without redundancy, and the formatting makes it easy to scan quickly.

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

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

Given the tool's moderate complexity (4 parameters, 1 required), comprehensive annotations, and 100% schema coverage, the description provides complete context. It covers purpose, parameters, examples, and usage guidelines, making it fully adequate for an agent to understand when and how to use this tool effectively.

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 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by listing parameters with their defaults, but doesn't provide additional semantic context like edge cases or usage examples beyond what's in the schema. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Create basic 3D primitive object') and resource ('in Blender scene'), with explicit differentiation from sibling tools like 'execute_blender_code' for complex geometry. It goes beyond just restating the name/title by specifying what type of object is created and where.

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 with 'Use when: Starting new scene, adding basic geometry' and 'Don't use when: Need complex custom geometry (use execute_blender_code instead)', naming a specific alternative tool. This gives clear context for when to choose this tool versus other options.

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

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

The description adds valuable behavioral context beyond annotations: 'Permanently removes object and its data. Cannot be undone via MCP.' and 'Error: "Object not found" if object doesn't exist'. While annotations already indicate destructiveHint=true and idempotentHint=true, the description clarifies the permanence and error behavior, enhancing 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 well-structured with clear sections (description, Args, Returns, Use when, Don't use when, Error) and avoids redundancy. It's appropriately sized, though the Args and Returns sections could be slightly more concise given the simple parameter and return.

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

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

For a destructive tool with one parameter and no output schema, the description is complete: it explains the action, usage guidelines, behavioral traits (permanence, error handling), and parameter semantics. It compensates well for the lack of output schema by mentioning return confirmation.

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 100% schema description coverage, the schema already documents the single parameter 'object_name' as 'Object to delete'. The description repeats this in the Args section but doesn't add significant semantic context beyond what's in the schema, such as naming conventions or constraints, meeting the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Delete object from Blender scene by name') and distinguishes it from sibling tools like 'blender_modify_object' or 'blender_get_object_info'. It specifies both the verb (delete) and resource (object) with precision.

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 provides 'Use when: Cleaning up scene, removing unwanted objects' and 'Don't use when: Temporarily hiding objects (no hide functionality in MCP currently)', offering clear guidance on when to use this tool versus alternatives. It even explains why not to use it for hiding.

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

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

The description adds valuable behavioral context beyond annotations: it mentions 'timeout protection included', 'Performance: Depends on file size and network speed', and 'Security: Validates URLs, enforces timeouts, saves within project directory'. While annotations cover basic safety (destructiveHint=false), the description provides practical implementation details about network dependencies and security measures that help the agent understand runtime 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 well-structured with clear sections (purpose, args, returns, examples, usage guidelines, performance, security) and front-loads the core functionality. While comprehensive, some sections like the detailed examples could be slightly condensed, but overall it's efficient with each section serving a clear 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 file download tool with no output schema, the description provides excellent completeness: it explains what the tool does, when to use it, parameter details, return information ('Download confirmation with file size, type, and save location'), practical examples, performance characteristics, and security considerations. This gives the agent sufficient context to use the tool effectively despite the lack of structured output documentation.

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 100% schema description coverage, the schema already documents all three parameters thoroughly. The description repeats parameter information in the Args section but adds minimal extra semantic context beyond what's in the schema. It meets the baseline of 3 by not being misleading, but doesn't significantly enhance parameter understanding beyond the structured 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 specific action ('download file from URL and save to Blender project directory') and resource ('assets, textures, and reference materials'), distinguishing it from sibling tools like blender_save_file for local files. It provides a verb+resource+scope combination that leaves no ambiguity about what the tool does.

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

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

The description explicitly states 'Use when: Downloading external assets, reference materials, textures from web' and 'Don't use when: Accessing local files (use save_file with local data)', providing clear when-to-use and when-not-to-use guidance with named alternatives. This helps the agent choose between this tool and blender_save_file.

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

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

The description adds valuable behavioral context beyond annotations. Annotations indicate it's not read-only, open-world, not idempotent, and not destructive. The description supplements this with performance details ('Network and file-size dependent, typically 5-60 seconds'), security info ('Validates asset IDs, downloads to secure project directory'), and clarifies the optional import behavior. It doesn't contradict annotations, but could mention more about idempotency or error handling.

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

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

The description is well-structured with clear sections (purpose, args, returns, examples, usage guidelines, performance, security). It's appropriately sized for a complex tool with 6 parameters and nested objects. Some redundancy exists (e.g., 'Args' repeats schema info), but overall it's efficient and front-loaded with the core 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 (6 parameters, nested objects, no output schema), the description is mostly complete. It covers purpose, usage, parameters, examples, performance, and security. However, it lacks details on return values beyond 'Download confirmation with file information and import status,' which could be more specific since there's no output schema. Annotations provide additional context, but the description could better explain idempotency or error scenarios.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description's 'Args' section repeats parameter names and basic info but doesn't add significant semantic value beyond the schema. Examples provide some usage context, but the baseline score of 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Download a PolyHaven asset and optionally import it directly into Blender.' It specifies the verb (download and optionally import), resource (PolyHaven asset), and distinguishes from sibling tools like 'blender_search_polyhaven' (for browsing) and 'blender_import_asset' (for importing already-downloaded assets).

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 provides usage guidelines: 'Use when: Adding professional assets to scenes, sourcing textures, environment setup' and 'Don't use when: Just browsing assets (use search_polyhaven instead).' This gives clear context for when to use this tool versus alternatives, including a named sibling tool for browsing.

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

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

The description adds valuable behavioral context beyond annotations, such as security restrictions ('Code is validated for dangerous patterns. System commands are restricted') and performance limitations ('Long-running code may hit timeout limits'). While annotations indicate destructiveHint=true, the description elaborates on the scope and constraints, though it could mention more about mutation effects.

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

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

The description is well-structured with clear sections (Args, Returns, Examples, Use when, Don't use when, Security, Performance), each sentence adds value without redundancy, and it's front-loaded with the core purpose. It efficiently conveys necessary information 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?

Given the tool's complexity (executing arbitrary code) and lack of output schema, the description does a good job covering key aspects like security, performance, and usage guidelines. However, it could provide more detail on error handling or return value structure to be fully complete, as the 'Returns' section is somewhat vague.

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 both parameters fully. The description adds minimal extra semantics, such as noting the code uses 'bpy API' and the timeout range, but doesn't provide significant additional meaning beyond what's in the schema. This meets the baseline for high schema coverage.

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

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

The description explicitly states the tool's purpose as 'Execute Python code using Blender's bpy API,' which is a specific verb+resource combination. It clearly distinguishes this tool from its siblings by emphasizing it's an 'escape hatch for complex operations not covered by other tools,' making the distinction explicit.

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

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

The description provides explicit guidance on when to use ('Complex operations, custom workflows, bpy API access') and when not to use ('Simple operations covered by dedicated tools'). It also references alternatives by mentioning 'other tools' and 'dedicated tools,' giving clear context for 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?

The description adds valuable behavioral context beyond annotations: performance characteristics ('typically 5-30 seconds'), confirmation of what gets returned ('Export confirmation with file size, format, and object count'), and practical use cases. While annotations cover basic hints (non-readOnly, non-destructive), the description provides operational insights that help the agent understand real-world 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 well-structured with clear sections (purpose, args, returns, examples, usage guidelines, performance). Every sentence adds value, with no redundant information. The front-loaded purpose statement immediately communicates the tool's function.

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 (4 parameters, nested objects, no output schema), the description provides comprehensive context: clear purpose, usage guidelines, parameter overview, return information, examples, and performance characteristics. It compensates well for the lack of output schema by describing what gets returned.

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 100% schema description coverage, the baseline is 3. The description's 'Args' section mostly repeats schema information, though it adds minimal context about 'objects' exporting all if unspecified. It doesn't 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 exports Blender objects or scenes to 3D formats, using specific verbs ('export') and resources ('Blender objects', 'entire scene', '3D formats'). It distinguishes from siblings like blender_get_screenshot (for previews) and blender_import_asset (for importing).

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 provides 'Use when' scenarios (sharing assets, exporting for other applications, backup) and 'Don't use when' alternatives (quick previews, recommending screenshot tools instead). This gives clear guidance on when to choose this tool over other options.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations by specifying the error condition ('Returns "Object not found" if object_name doesn't exist') and describing the return format options. It doesn't mention rate limits or authentication needs, but adds meaningful operational details.

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

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

The description is well-structured with clear sections (purpose, returns, usage guidelines, error handling) and every sentence adds value. It's front-loaded with the core purpose, followed by supporting details, with no redundant or unnecessary 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 read-only query tool with comprehensive annotations and 100% schema coverage, the description provides excellent contextual completeness. It covers purpose, usage guidelines, return formats, error conditions, and sibling tool differentiation. The lack of an output schema is compensated by the detailed return format descriptions in the description itself.

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 fully documents both parameters. The description adds minimal value beyond the schema by providing an example for object_name ('e.g., "Cube", "Camera"') and clarifying the default for response_format, but doesn't add significant semantic context. This meets the baseline for high schema coverage.

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

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

The description clearly states the specific action ('Query detailed properties') and resource ('specific Blender object by name'), and distinguishes it from sibling tools by specifying it's for individual objects rather than entire scenes. The verb 'query' is precise and the scope is well-defined.

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 with 'Use when: Need specific object details before modifying' and 'Don't use when: Querying entire scene (use blender_get_scene_info instead)', including a named alternative tool. This gives clear context for when to choose this tool over others.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds valuable context beyond annotations: performance ('Fast network request, typically 1-3 seconds') and licensing behavior ('Returns CC0 licensing information for all assets'), which are not captured in 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?

Well-structured with clear sections (description, Args, Returns, Examples, Use when/Don't use when, Performance, License). Every sentence adds value, such as performance and licensing details, with no redundant information. It's front-loaded with the core 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 low complexity (2 parameters, no output schema), the description is complete: it covers purpose, usage guidelines, parameters (via schema), behavioral context (performance, licensing), and examples. With annotations providing safety hints, no critical information is missing for effective agent use.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description's 'Args' section repeats the schema information without adding new meaning (e.g., it doesn't explain what 'asset ID' format is or provide examples beyond those in the schema). Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action ('Get detailed information') and resource ('about a specific PolyHaven asset'), distinguishing it from siblings like blender_download_polyhaven_asset (for downloading) and blender_search_polyhaven (for searching). The title reinforces this with 'Get PolyHaven Asset Details'.

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

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

Explicit 'Use when' and 'Don't use when' sections provide clear guidance on when to use this tool versus alternatives, naming blender_download_polyhaven_asset as the alternative for downloading. This directly addresses sibling tool differentiation.

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

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

The description adds valuable behavioral context beyond annotations: 'Performance: Fast network request, typically 1-3 seconds' and 'Content: Updated daily based on community downloads and ratings.' While annotations already indicate read-only, open-world, idempotent, and non-destructive behavior, these additional details about performance frequency and update cadence provide helpful operational context for the agent.

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

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

The description is well-structured with clear sections (description, args, returns, examples, usage guidance, performance, content). While somewhat lengthy, each section serves a purpose and is front-loaded with the core functionality. The examples are particularly helpful but contribute to the length.

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

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

For a read-only query tool with comprehensive annotations and full schema coverage, the description provides good contextual completeness. It explains the tool's purpose, usage guidelines, performance characteristics, and update frequency. The main gap is the lack of output schema, but the description does specify what's returned ('List of popular assets with download counts and ratings').

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 100% schema description coverage, the schema already documents all three parameters thoroughly. The description's 'Args' section essentially repeats what's in the schema without adding significant additional semantic context. The examples provide some usage patterns but don't add parameter meaning beyond the schema's enum values and descriptions.

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

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

The description clearly states the tool's purpose: 'Get trending and popular assets from PolyHaven' and specifies it returns 'most downloaded and highly-rated assets across different categories.' It distinguishes from the sibling 'blender_search_polyhaven' by focusing on trending/popular assets rather than specific criteria searches.

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 with 'Use when: Discovering trending assets, finding high-quality content, asset inspiration' and 'Don't use when: Searching for specific criteria (use search_polyhaven instead).' It names the alternative tool and gives clear context for when to use this tool versus the sibling.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context beyond this: it specifies the scope ('complete scene metadata including all objects'), output formats, and behavioral details about what data is returned (objects, materials, collections, world). No contradiction with annotations.

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

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

The description is well-structured and front-loaded with the core purpose. Each section (purpose, args, returns, usage guidelines) is concise and earns its place with no redundant information. The text efficiently communicates essential information without 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?

Given the tool's complexity (scene-wide query), rich annotations, and lack of output schema, the description provides complete context. It explains what data is returned, output formats, and usage boundaries. The annotations cover safety aspects, and the description fills in behavioral details, making it fully adequate for an agent to use the tool correctly.

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

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

Schema description coverage is 100%, with the parameter 'response_format' fully documented in the schema. The description adds minimal value beyond the schema by briefly mentioning the parameter in the 'Args' section and describing output formats, but doesn't provide additional semantic context. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose with specific verbs ('Query', 'Returns') and resources ('Blender scene hierarchy, objects list, materials, and world settings'). It distinguishes from sibling tools like blender_get_object_info (single object) by emphasizing 'complete scene metadata' and 'all objects'.

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

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

The description explicitly provides usage guidance with 'Use when:' and 'Don't use when:' sections. It names specific scenarios ('understand current scene state, find object names, verify scene setup') and directs to alternatives ('use create/modify tools instead'), clearly differentiating from sibling modification tools.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, but the description adds valuable behavioral context: performance constraints ('Limited to 800px max dimension for performance', 'Larger images take longer to process and transfer'), and clarifies it captures the 'current' viewport state. No contradiction with annotations.

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

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

Well-structured with clear sections (description, args, returns, usage guidelines, performance). Every sentence adds value: first states purpose, second adds constraint, third documents parameter, fourth explains returns, fifth/sixth provide usage guidelines, seventh adds performance context. 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 simple read-only tool with good annotations and no output schema, the description is complete: explains what it does, when to use it, parameter details, return format, and performance considerations. Covers all necessary context 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 description coverage is 100% with the parameter fully documented in the schema. The description mentions 'max_size (optional)' and repeats the range, adding minimal value beyond the schema. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description clearly states the specific action ('Capture current viewport as base64 image') and resource ('current 3D viewport view'). It distinguishes from siblings like 'blender_render' (implied) by specifying it's for viewport screenshots, not high-resolution renders.

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 provides 'Use when' scenarios (visualizing scene state, checking results, debugging) and 'Don't use when' guidance (need high resolution renders, use Blender render instead). This clearly distinguishes when to use this tool versus 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?

The description adds valuable behavioral context beyond what annotations provide. Annotations indicate read-only, non-destructive, and idempotent operations, but the description adds 'Performance: Instant operation, negligible performance impact' which gives practical implementation insight. It doesn't contradict annotations and provides additional useful information about execution characteristics.

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

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

The description is well-structured with clear sections (description, Args, Returns, Examples, Use when, Don't use when, Performance) and every sentence earns its place. It's appropriately sized for the tool's complexity, front-loading the core purpose while providing necessary details in organized subsections without redundancy.

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

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

Given the tool's simple nature (single parameter with full schema coverage, read-only operation with comprehensive annotations), the description provides complete contextual information. It covers purpose, usage guidelines, parameter examples, behavioral characteristics, and distinguishes from related tools, making it fully adequate for agent understanding despite the lack of output schema.

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

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

With 100% schema description coverage for the single parameter, the schema already documents the 'operation' parameter with its enum values and default. The description adds minimal value beyond the schema by mentioning the parameter in the Args section and providing examples, but doesn't add significant semantic context beyond what's already in the structured schema.

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

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

The description clearly states the tool's purpose with specific verbs ('List all supported file formats') and resources ('import and export operations'), distinguishing it from sibling tools like import_asset and export_asset. It goes beyond just restating the name/title by specifying what information is provided ('comprehensive format information with capabilities and recommended use cases').

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 on when to use ('Use when: Planning asset workflows, choosing formats, understanding capabilities') and when not to use ('Don't use when: Actual import/export operations (use import_asset/export_asset instead)'), including named alternatives. This gives clear context for tool selection versus its siblings.

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

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

The description adds valuable behavioral context beyond annotations: it discloses performance characteristics (1-10 seconds typical), lists supported file formats, and provides examples of usage patterns. While annotations cover basic safety (non-destructive, non-readonly), the description enhances understanding with practical implementation details.

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

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

The description is well-structured with clear sections (purpose, args, returns, examples, usage guidelines, performance). While comprehensive, some sections like the format list could be more concise. Overall, it's efficiently organized with most sentences adding clear 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 (3 parameters with nested objects, no output schema), the description provides excellent contextual completeness. It covers purpose, usage guidelines, parameters, examples, performance expectations, and distinguishes from alternatives. The combination of description and schema provides everything needed for effective tool 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?

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description adds minimal extra semantic value through the 'Args' section and examples, but doesn't provide significant additional meaning beyond what's in the structured schema. This meets the baseline for high schema coverage.

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

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

The description clearly states the tool imports external 3D assets into Blender scenes with comprehensive options. It specifies the action (import), resource (external 3D assets), and context (Blender scene), and distinguishes itself from sibling tools like blender_create_primitive by focusing on external assets rather than internal creation.

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 includes explicit 'Use when' and 'Don't use when' sections, providing clear guidance on when to use this tool (adding external assets, importing models/textures) versus alternatives (object creation tools for primitives). This directly addresses sibling tool differentiation.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context beyond annotations by stating 'Performance: Fast operation, minimal performance impact' and clarifying the tool provides a 'comprehensive view of scene organization structure, including nested collections and object membership', which helps the agent understand behavioral traits like speed and output structure.

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, starting with the core purpose. However, it includes some redundancy (e.g., repeating parameter names in the 'Examples' section that are already in the schema) and could be slightly more streamlined. Overall, most sentences earn their place by adding context or guidance.

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 low complexity (2 parameters, no output schema), rich annotations (readOnlyHint, idempotentHint, etc.), and 100% schema coverage, the description is complete. It covers purpose, usage guidelines, performance context, and examples, providing all necessary information for an agent to select and invoke the tool correctly without over-explaining.

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 both parameters ('include_objects' and 'object_details') well-documented in the schema. The description adds minimal value beyond the schema by providing examples of parameter combinations (e.g., 'Simple list: include_objects=false, object_details=false'), but doesn't explain semantics or usage nuances not already in the schema. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool's purpose with specific verb ('List') and resource ('collections in the current Blender scene'), and distinguishes it from sibling tools like 'blender_create_collection' by emphasizing it's for listing rather than creating. The title 'List Scene Collections' reinforces this clarity.

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

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

The description explicitly states 'Use when: Understanding scene structure, managing assets, planning organization' and 'Don't use when: Creating new collections (use create_collection instead)', providing clear guidance on when to use this tool versus alternatives. This directly addresses sibling tool differentiation.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: performance characteristics ('Fast operation, minor impact with large recursive listings') and security boundaries ('Only accesses files within project directory structure'). No contradiction with annotations.

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

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

The description is well-structured with clear sections (purpose, args, returns, examples, usage guidelines, performance, security). While comprehensive, some sections like the performance and security notes could be more concise. The front-loaded purpose statement is clear, but the overall length is slightly longer than 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 read-only listing tool with comprehensive annotations and 100% schema coverage, the description provides good contextual completeness. It covers purpose, usage guidelines, examples, performance, and security considerations. The main gap is the lack of output schema, but the description's 'Returns' section provides reasonable metadata information about what to expect.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description's 'Args' section repeats what's in the schema without adding significant semantic context beyond what's already captured in structured fields. The examples provide some usage context but don't fundamentally enhance parameter 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's purpose with specific verb 'List' and resource 'files and directories in the Blender project or specified directory'. It distinguishes itself from siblings like create_directory and save_file by being a read-only listing operation rather than a creation/modification tool.

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

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

The description explicitly provides 'Use when' scenarios (project organization, asset management, file system navigation) and 'Don't use when' alternatives (creating new files or directories, directing to create_directory/save_file). This gives clear guidance on when to select this tool versus other available options.

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

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

The description adds valuable behavioral context beyond annotations: it specifies that 'at least one transform property must be provided' (a constraint not in annotations) and describes the return format ('Success message with updated properties'). Annotations already cover read/write status (readOnlyHint=false), idempotency (idempotentHint=true), and safety (destructiveHint=false), so the description appropriately supplements rather than contradicts them.

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

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

The description is well-structured and front-loaded with the core purpose, followed by parameter details and usage guidelines. Every sentence serves a clear purpose: defining the tool's function, specifying parameters, stating constraints, describing returns, and providing usage guidance. There is no wasted 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?

For a transformation tool with comprehensive annotations (covering mutation, idempotency, and safety) and full schema coverage, the description provides complete contextual information. It explains the tool's purpose, parameter constraints, return format, and usage guidelines relative to alternatives. No output schema exists, but the description adequately describes the return value.

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

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

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description repeats some parameter information (e.g., 'rotation in radians') but adds minimal new semantics beyond the schema. It does clarify the 'at least one transform property' constraint, which provides some additional context about parameter interactions.

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

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

The description clearly states the tool's purpose with specific verbs ('modify transforms', 'update location, rotation, and/or scale') and identifies the resource ('existing Blender object'). It distinguishes from sibling tools by explicitly contrasting with 'create_primitive' for object creation, making its scope 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 guidelines with 'Use when: Positioning, rotating, or scaling existing objects' and 'Don't use when: Creating new objects (use create_primitive instead)'. It names a specific alternative tool and clearly defines the appropriate context, leaving no ambiguity about when to select this tool.

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

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

The description adds valuable behavioral context beyond what annotations provide. While annotations indicate this is a destructive operation (destructiveHint: true), the description elaborates with performance impact details ('Moderate impact depending on mesh complexity, typically 5-60 seconds') and clarifies what gets preserved (visual quality, essential attributes). This provides practical implementation context that annotations alone don't convey.

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

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

The description is well-structured with clear sections (purpose, parameters, returns, examples, usage guidance, performance). Every sentence adds value, with no redundant information. The front-loaded purpose statement immediately communicates the tool's core function.

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

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

For a destructive optimization tool with no output schema, the description provides excellent completeness. It covers purpose, parameters, return format, examples, usage scenarios, performance characteristics, and alternatives. The combination of detailed description and comprehensive annotations (including destructiveHint) gives the agent sufficient context to use this tool 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?

With 100% schema description coverage, the schema already documents all parameters thoroughly. The description's parameter section mostly repeats what's in the schema, though it adds minor context about the trade-off between target_poly_count and decimation_ratio approaches through examples. This meets the baseline expectation when schema coverage is complete.

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

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

The description clearly states the specific action ('optimize 3D assets for better performance') and the methods used ('through mesh decimation and cleanup'), distinguishing it from siblings like export or modification tools. It explicitly mentions reducing polygon count and optimizing geometry while preserving visual quality.

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 when' guidance (optimizing for real-time applications, reducing file sizes, performance improvements) and 'Don't use when' guidance (preserving maximum detail for rendering, with an alternative named: 'use export with high quality instead'). This clearly distinguishes when to choose this tool over 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?

The description adds valuable behavioral context beyond annotations: it explains the 'moderate impact depending on scene size and object count' (performance implications), describes what gets created and moved (collections and objects), and clarifies the intelligent/organizational nature. While annotations already indicate destructiveHint=true, the description elaborates on what gets modified without contradiction.

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

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

The description is well-structured with clear sections (purpose, args, returns, examples, usage guidelines, performance). While comprehensive, some redundancy exists between the 'Args' section and schema descriptions. Every sentence serves a purpose, but the parameter documentation could be more concise given the schema coverage.

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

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

For a destructive tool with 3 parameters and no output schema, the description provides excellent completeness: it explains what the tool does, when to use it, parameter usage through examples, performance characteristics, and return value expectations ('organization summary'). The combination of purpose, guidelines, and behavioral context makes this highly 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 100% schema description coverage, the schema already documents all three boolean parameters thoroughly. The description's 'Args' section repeats this information without adding significant semantic context beyond what's in the schema. The examples provide usage patterns but don't enhance parameter understanding beyond the schema's descriptions.

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

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

The description clearly states the tool's purpose with specific verbs ('organize', 'creates collections', 'moves objects') and resources ('scene assets', 'collections', 'objects'). It distinguishes from siblings by focusing on automated organization by type rather than manual collection management (blender_add_to_collection) or individual object 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 provides explicit 'Use when' and 'Don't use when' sections with concrete scenarios ('cleaning up disorganized scenes', 'fine-grained manual control needed'). This gives clear guidance on when to choose this automated tool versus alternatives that offer more control.

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

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

The description adds valuable behavioral context beyond annotations: it discloses performance characteristics ('typically fast for assets under 100MB') and security constraints ('Validates file paths and saves within project directory'). While annotations already indicate destructiveHint=true, the description provides practical implementation details that help the agent understand operational boundaries.

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

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

The description is well-structured with clear sections (purpose, args, returns, examples, usage guidelines, performance, security) and front-loaded with the core functionality. While comprehensive, some sections like the detailed examples could be slightly condensed, but overall it's efficiently organized with minimal 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 (file operations with security implications) and the absence of an output schema, the description provides excellent completeness. It covers purpose, parameters, return values, examples, usage scenarios, performance expectations, and security constraints - everything needed for an agent to use this tool effectively despite the lack of structured output documentation.

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 100% schema description coverage, the schema already documents all three parameters thoroughly. The description's 'Args' section essentially repeats what's in the schema without adding significant additional semantic context. The examples provide some usage context but don't enhance parameter understanding beyond the schema's descriptions.

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

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

The description clearly states the specific action ('Save base64 encoded file data') and resource ('to the Blender project directory'), with examples distinguishing it from sibling tools like blender_export_asset or blender_download_file. It explicitly mentions supporting various file types including assets, textures, and project files.

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 when' and 'Don't use when' sections with clear alternatives named ('use Blender export tools'). It gives concrete scenarios like 'Saving downloaded assets, exporting files, project file management' and warns against using it for 'Creating files from Blender operations'.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable context beyond this: it discloses performance ('Network-dependent, typically 1-5 seconds') and licensing information ('All PolyHaven assets are CC0'), which are not captured in annotations. No contradiction with annotations exists.

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

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

The description is well-structured with clear sections (Args, Returns, Examples, Use when/Don't use when, Performance, License), making it easy to scan. It's appropriately sized with no redundant sentences, though it could be slightly more concise by integrating some details (e.g., the second sentence about PolyHaven's offerings is helpful but not strictly necessary for tool invocation).

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 moderate complexity (5 parameters, no output schema), the description is largely complete. It covers purpose, usage guidelines, parameters (via schema with 100% coverage), behavioral traits (performance, licensing), and distinguishes from siblings. The main gap is the lack of output schema, but the description partially compensates by mentioning return values ('Search results with asset metadata, thumbnails, and download options').

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

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

Schema description coverage is 100%, meaning all parameters are documented in the schema. The description lists parameters and provides examples, but these mostly restate what's in the schema (e.g., 'query (optional): Search query for assets' mirrors the schema description). It adds minimal extra semantics, such as example usage, but doesn't significantly enhance understanding beyond the schema's baseline.

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

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

The description clearly states the tool searches the PolyHaven library for free 3D assets, textures, and HDRIs, specifying the resource (PolyHaven library) and action (search). It distinguishes from sibling tools by mentioning the alternative 'download_polyhaven_asset' for downloading specific assets, making the purpose specific and well-differentiated.

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 provides 'Use when' scenarios (finding reference assets, texture sourcing, environment creation) and 'Don't use when' guidance (downloading specific assets, with a named alternative 'download_polyhaven_asset'). This gives clear, actionable context for when to use this tool versus alternatives.

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

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

Annotations provide readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable context beyond annotations: it specifies that it modifies 'existing material' (prerequisite), mentions specific property types (PBR material properties), and provides concrete examples of value formats. This enhances understanding of the tool's behavior without contradicting annotations.

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

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

The description is well-structured with a clear purpose statement, parameter explanations, and practical examples. Each section earns its place, though the 'Returns: Success confirmation' line is somewhat redundant since it doesn't elaborate on what confirmation entails. Overall efficient 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?

For a mutation tool with no output schema, the description provides adequate context: clear purpose, parameter guidance, examples, and behavioral context. It covers the essential aspects of modifying material properties, though additional details about error conditions or material existence validation could further enhance 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?

With 67% schema description coverage, the description compensates well by explaining the 'property' enum values and 'value' parameter semantics (color as RGBA array vs number for other properties). The examples clarify how different property types map to different value formats, adding meaningful context beyond the schema's technical specifications.

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 modifies specific properties of existing materials, with specific examples of PBR properties like color and metallic. It distinguishes from sibling tools like blender_create_material (creation vs modification) and blender_apply_material (application vs property setting). However, it doesn't explicitly contrast with blender_modify_object, which might handle different object types.

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 needing to update material properties, but doesn't provide explicit guidance on when to use this versus alternatives like blender_create_material for new materials or blender_apply_material for assigning materials to objects. No when-not-to-use scenarios or prerequisites are mentioned.

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