ClaudeKit Blender MCP

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.