blender-mcp

by sandraschi

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.5.0
Disambiguation2/5
Several tools have overlapping purposes (e.g., blender_mesh, construct_object, generate_blender_script all create objects). Duplicate tools like blender_addons and manage_blender_addons cause confusion. The portmanteau pattern groups many operations under one tool, which reduces tool count but still leaves ambiguous boundaries between tools that can achieve similar results through different means.
Naming Consistency3/5
Most tools follow a 'blender_*' pattern, but there are outliers like 'clear_scene', 'generate_blender_script', and 'import_cad_file' that deviate. Some tools have long portmanteau names with internal operations, which is consistent but verbose. Overall, the naming is readable but not perfectly uniform.
Tool Count2/5
With 67 tools, the server feels overloaded. While Blender is complex, many tools could be merged further or simplified. The portmanteau design helps, but the count still exceeds what an agent can easily navigate, leading to potential decision paralysis.
Completeness5/5
The tool set covers nearly every major Blender domain: modeling, animation, materials, lighting, rendering, video editing, rigging, sculpting, physics, particles, asset management, validation, and more. It even includes AI-driven tools and integration with external services. There are no obvious gaps for a general 3D workflow.
Average 3.3/5 across 67 of 67 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 4 community issues answered or closed in the last 6 months
- 64 commits in the last 12 weeks
- Last stable release on July 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'create' (a mutation), but provides no information about side effects, required permissions, effects on existing collections, or return values. The description is minimally honest but insufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (4 words), but this is not concise in a useful sense—it omits essential information. It fails to earn its place by adding value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and an output schema, the description is completely inadequate. It doesn't explain what creating a collection entails, how it relates to sibling tools, or what the output schema represents. In a complex system like Blender, such minimalism is unacceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'collection_name' is not described beyond its name in the schema. The description adds no meaning about the format, constraints, or expected values. With 0% schema coverage, this is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new collection' is a tautology that merely restates the tool name. It lacks specificity about what a 'collection' refers to in the Blender context (e.g., object collection vs. data collection) and does not differentiate from sibling tools like 'add_to_collection'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'add_to_collection'), nor are there any prerequisites or context for when creation is appropriate. The description is silent on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose key behaviors: whether the operation is idempotent, what happens if object already in collection, required permissions, or side effects. The single sentence adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but underspecified. While concise, it lacks necessary information to be useful. Every sentence should earn its place; here one sentence does not sufficiently describe the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with 2 params and no annotations, but the description is still incomplete. It does not mention return values (though output schema exists), preconditions, or any contextual details that an agent needs for correct invocation. Falls short for a tool among many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have no descriptions in schema (0% coverage). The description adds no meaning beyond the parameter names (collection_name, object_name). An AI agent gets no help understanding valid values or format. Baseline should compensate for low schema coverage, but fails entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb and resource ('Add an object to a collection') but is generic. Does not differentiate from many related sibling tools like 'create_collection' or 'manage_object_construction', leaving ambiguity when to use this over alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No description of prerequisites (object must exist, collection must exist), no exclusions or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions operations but does not describe side effects, required state (e.g., must have an active material), error conditions, or whether operations are destructive. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by a clear bullet list of operations. No unnecessary words, though it could benefit from a brief note on parameter usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, no schema descriptions, no annotations), the description is severely incomplete. It does not explain how to use parameters, prerequisites, or expected outcomes for each operation. An output schema exists but is not visible, and the description adds little context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter documentation. The description adds no meaning beyond listing operation names; none of the 13 parameters (e.g., material_name, node_type) are explained or mapped to the operations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Shader node graph operations for materials' and lists four specific operations, distinguishing it from sibling tools like blender_materials or blender_geonodes which handle different aspects of materials or geometry nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like blender_materials or blender_geonodes. The description only lists operations without contextual usage advice or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description does not disclose any behavioral traits such as side effects, permissions, idempotency, or file overwriting behavior. It only lists operations without depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loads the purpose. However, it sacrifices completeness for brevity, leaving out parameter details that are necessary for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not explain return values or behavior. With 10 parameters and no schema descriptions, the description is inadequate 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It mentions a few parameters implicitly (pattern, input_dir, name_pattern) but ignores width, height, source_format, target_format, etc. The meaning of many parameters remains unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it handles batch image and mesh export operations and lists specific operations (resize, convert, export), which is clear. However, it fails to differentiate from sibling tools like blender_export, which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., blender_export or blender_import). No mention of prerequisites, common use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It doesn't mention side effects (e.g., file overwriting, scene modification), error handling, or export limits. Only lists operations without behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded, but the bullet list for operations is minimal. Could be more structured (e.g., grouping parameters by operation). Adequate but not highly efficient for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, 0% schema coverage, and no annotations, the description is far from complete. It doesn't explain output format, error scenarios, or how operations interact with parameters. Even with an output schema, major gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains operation and hints at file_format via bullet points, but 7 of 9 parameters (e.g., global_scale, apply_transforms) are undefined. No parameter-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool exports Blender scenes/objects to interchange and game-engine formats. Lists specific operations (glTF, FBX, etc.) and platform presets, distinguishing it from sibling tools like blender_import or blender_render.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use each operation, how presets differ from manual format selection, or prerequisites. The sibling blender_export_presets exists but isn't referenced, and the description doesn't help an agent choose between options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions creating objects but omits details about permissions, state changes, or potential destructive actions. The tool likely creates new objects, but the description does not confirm safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but includes a lengthy list of operations. It could be restructured to front-load essential information more effectively, such as grouping type-specific parameters instead of listing them individually.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 22 parameters, no annotations, and low schema coverage, the description is incomplete. It does not cover all parameters sufficiently, nor does it explain the output behavior despite having an output schema. Agents would need to infer many details from parameter defaults alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With low schema description coverage (27%), many parameters lack meaningful descriptions (e.g., chair_type, table_type). The description adds some context for the 'operation' parameter but fails to explain other critical parameters like 'dimensions', 'location', or per-type specifics, which would help the agent configure the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create furniture and complex objects in Blender' and enumerates specific operations (e.g., create_chair, create_table), making the tool's purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'construct_object', which have overlapping capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'construct_object', 'blender_scene'). It lacks any 'when to use' or 'when not to use' context, leaving the agent to infer usage from the operation list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as side effects, permission requirements, or whether operations are destructive. The list of operations implies mutations but no explicit safety info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded with purpose. Bullet list of operations is clear, though could be more structured. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 undocumented parameters and an output schema not described, the description is insufficient for an agent to use the tool correctly. Critical details for parameter usage and return values are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 15 parameters, the description fails to explain parameter meanings or how they map to operations. For example, 'node_type' defaulting to 'GeometryNodeMeshCube' is unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Geometry Nodes graph operations (procedural modeling)' and lists specific sub-operations, distinguishing it from sibling tools like blender_mesh or blender_modifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or when-not-to-use instructions. The description only lists operations without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists operations including delete_object, but does not disclose side effects (e.g., permanent deletion, scene modification) or prerequisites (e.g., Blender running). The description focuses on capabilities rather than behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose, starting with a meta rationale in caps that is not immediately useful. The core purpose is buried after the rationale. It could be shortened and front-loaded with the actual purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite many parameters and operations, the description does not explain return values, error handling, or prerequisites. It lists operations but lacks detail on which parameters apply to which operation. The presence of an output schema is not mentioned, so the agent has no guidance on responses.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description adds some context (e.g., linking operations to required parameters) but does not significantly enhance understanding beyond the schema. Many parameters have detailed schema descriptions already, so the description provides minimal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create and manipulate mesh objects in Blender with comprehensive primitive support.' It lists many operations, distinguishing this tool as the mesh-specific one among many blender tools. The portmanteau pattern rationale explains consolidation, but the description could be more explicit about the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool vs. alternatives. It includes a 'PORTMANTEAU PATTERN RATIONALE' that explains design but not usage. There is no mention of when to prefer this tool over other blender tools like blender_modifiers or blender_transform.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only mentions that screenshot_viewport prefers a live GUI session. No info on destructive actions, performance impact, or file overwriting behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a list and rationale, but the portmanteau pattern rationale upfront adds unnecessary length. Could be more focused on essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 23 parameters and multiple sub-operations, the description lacks details on how parameters map to operations. Without output schema context, it's insufficient for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any parameters; e.g., frames, angles, elevation_deg are not described. The list of sub-operations does not compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it consolidates rendering operations, and lists distinct sub-operations (render_preview, render_animation, etc.), which differentiates it from sibling tools like blender_export or blender_compositor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists many operations but provides no guidance on when to use each sub-operation or alternatives. No explicit context for selection, e.g., when to use render_animation vs render_turntable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral details. It only mentions script generation, omitting side effects (e.g., does it execute the script?), prerequisites (Ollama running), error handling, or return format. This leaves the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but overly terse. It front-loads the purpose but sacrifices necessary behavioral and parameter details, making it minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description omits any mention of return values, script behavior, or integration with Blender. Given 3 parameters and no parameter descriptions, it leaves significant gaps for a generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no parameter information. It does not explain the prompt format, model selection, or ollama_url usage, forcing reliance on default names and types without context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Blender Python script from a natural language prompt using Ollama, which is a specific verb-resource-method combination. It distinctively mentions 'local LLM (Ollama)', differentiating it from other AI-related sibling tools like blender_ai_generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implicitly suggests usage via Ollama but fails to indicate prerequisites, use cases, or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only lists operations without disclosing side effects, required scene state, or consequences (e.g., modifying the compositor graph).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and action-oriented, using bullet points for operations, but lacks a clear structural breakdown linking parameters to operations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and no annotations, the description omits critical details like which parameter combinations are valid for each operation, output behavior, and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 13 parameters (e.g., operation values, node_type, glow parameters), leaving their meaning entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool handles 'Compositor graph operations for post-processing' and lists specific operations (enable, add_node, connect_nodes, glow), distinguishing it from sibling tools like blender_render or blender_shaders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives, nor any prerequisites or conditions for using specific operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It lists operations but fails to disclose critical aspects such as potential destructive actions (e.g., clear_scene), required permissions, or side effects. This is insufficient for a tool with multiple operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a brief header followed by a bulleted list of operations. It is moderately concise but could be more succinct by grouping related operations or removing redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 10 parameters and 12 operations, yet the description omits important context such as return values (despite an output schema existing), error handling, or behavior for edge cases. For a complex tool, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all 10 parameters (100% coverage). The description adds minimal extra meaning beyond the schema, such as listing operation types and noting parameter purposes (e.g., 'Position as [x,y,z]'). This meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for 'scene management' and lists 12 specific operations, making the purpose evident. However, it does not distinguish itself from sibling tools like create_scene or clear_scene, which perform similar tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists operations but provides no guidance on when to use this tool versus the many sibling tools (e.g., create_scene, clear_scene). There is no mention of prerequisites, alternatives, or context for choosing this tool over individual ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description merely says 'Update,' implying mutation without disclosing side effects, permissions, or behavioral traits beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences, front-loading the action and listing keys. Every sentence serves a purpose, though some information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no schema descriptions, and no annotations, the description lacks critical details about usage, such as how to partially update config or expected return values, despite having an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only lists parameter names, which adds no meaning beyond the schema's property names. No explanation of allowed values, formats, or constraints, despite 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates webapp config and lists the configurable keys, distinguishing it from sibling tools like config_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., config_get) or when not to use it. No context provided for typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions 'headless', but lacks details on side effects, error handling, security implications, or limitations (e.g., script duration, file access). The parameter schema mentions bpy API, but the description does not add behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise but lacks any structure or detail beyond the core purpose. It is not verbose, but could benefit from additional context without becoming wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description is insufficient. It does not explain what happens after execution (e.g., return values, errors, side effects) nor how it fits among many Blender-related siblings. The tool is simple but context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the only parameter has a description). The tool description does not add additional meaning to the parameter beyond what the schema already provides. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Execute), resource (Python script), and context (headless). It differentiates from siblings like 'generate_blender_script' or 'blender_ai_generate' by focusing on direct execution rather than generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many sibling tools that involve scripting (e.g., 'generate_blender_script', 'blender_ai_generate'), there is no explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral transparency. It mentions handling creation, setting weights, and analysis, but omits critical details: that the 'operation' parameter selects the action, that only one operation runs per call, that parameters are specific to certain operations, and whether the tool is destructive (modifies blend files) or read-only. The description is too abstract for a tool with 14 parameters and multiple modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose ('Comprehensive shape key management') and then itemizing key use cases. Every word earns its place; there is no redundancy or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, one enum for operation, multiple operational modes), the description fails to explain how the 'operation' parameter dictates which parameters are relevant. It does not mention that the tool can perform only one operation per call. Although an output schema exists (not shown), the description leaves the agent without a mental model of how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions. For example, 'viseme_type' is already described in the schema. The description does not clarify parameter interdependencies or usage patterns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's domain ('shape key management for facial animation and VRM avatars') and lists specific use cases (viseme creation, blink, expressions, VRM compliance). Although the verb 'management' is broad, the details distinguish it from sibling tools that handle mesh, animation, or rigging. A score of 5 would require a more action-oriented first sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for facial animation and VRM avatars but provides no explicit guidance on when to use this tool versus alternatives (e.g., manual Blender shape key editing, other scripting tools). There is no 'when not to use' or mention of sibling tools. Without such guidance, an agent lacks decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It does not mention side effects, permissions, or safety. The term 'Advanced' lacks specifics. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose. Could be more concise by removing vague terms like 'hybrid environments', but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters and no output schema shown, the description omits many operations (e.g., create_proxy, optimize_for_vr). It covers only importing, cleaning, and VR prep, leaving the full scope unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema; it only provides a high-level overview without explaining parameter relationships or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'Gaussian Splatting management' and lists importing, cleaning, and VR preparation. It distinguishes from general Blender tools but could be more specific about the range of operations (e.g., cropping, collision mesh).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'agentic_blender_workflow' or 'intelligent_3d_processing'. The description only mentions hybrid environments and VR platforms, but no exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It states the tool performs checks but does not describe whether it modifies the model, returns errors, or requires any permissions. The read-only nature and side effects are not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two sentences, front-loading the core purpose. However, it could be slightly more informative without sacrificing brevity, such as mentioning that it reports issues or lists validation results.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and an output schema (not shown), the description fails to mention what the tool returns (e.g., a list of validation errors, pass/fail). For a validation tool, this is a notable gap. The description is too brief for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (90%), so the schema already details most parameters. The description adds little beyond naming the tool as 'comprehensive validation tools' and mentioning platforms. It does not explain the meaning of various operation types or parameter interplay beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool performs comprehensive validation and pre-flight checks for avatars and 3D models across multiple platforms (VRChat, Resonite, Unity). It uses specific verbs and resources, though it does not explicitly distinguish itself from sibling tools that may also perform validation aspects (e.g., blender_mesh, blender_rigging).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or comparative advice. For a tool with many sibling tools covering similar domains, this omission is significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether changes are destructive, reversible, or require specific Blender versions/addons. It only mentions platform compatibility vaguely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words. Front-loaded with the purpose and context. Conciseness is excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (unknown content), the description is too high-level for a tool with 13 parameters and multiple sub-operations. It does not explain which operation to use for different tasks or provide workflow guidance, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema itself documents all parameters. The tool description adds no additional meaning beyond that baseline. A score of 3 is appropriate as the description does not detract but neither does it enhance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states VRM metadata management for avatar configuration, but does not explicitly list the specific operations (e.g., set first person offset, configure spring bones) that are evident from the input schema. This ambiguity may require the agent to inspect the schema for full purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings (none are VRM-specific, but many Blender tools exist). It also does not state prerequisites, such as needing a VRM avatar loaded or platforms like VRChat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry full behavioral transparency. It only states the action without disclosing side effects (e.g., scene existence handling, impact on viewport) or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loaded with the verb and resource. It is appropriately sized for a simple tool, though a second sentence with key caveats could be added without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, required, simple schema), the description is adequate but not complete. It does not clarify what 'active scene' means in Blender or explain the output schema, leaving minor gaps for an AI agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds the phrase 'by name', which implies 'scene_name' is the name. This is minimal improvement; a more explicit description (e.g., 'Name of the scene to set as active') would be better.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('active scene') with method ('by name'). It distinguishes from siblings like 'create_scene' and 'list_scenes', though it could clarify the concept of 'active scene'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'create_scene', 'clear_scene'). No prerequisites or context provided, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral traits. It does not disclose side effects, requirements (e.g., active object), permissions, or what happens if parameters are incompatible. The operation list implies creation/assignment but gives no details on state changes or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with a clear purpose then listing operations in a bullet-style. It is concise with no redundant sentences. Each sentence adds value, though the parameter descriptions in schema are separate. Slightly verbose but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (23 parameters, 7 operations), the description is incomplete. It does not map operations to relevant parameters, advise on which parameters to set for each operation, or explain the output. An output schema exists but is not summarized. The agent lacks sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds a high-level operation list but does not explain parameter semantics beyond what the schema already provides. For instance, it doesn't clarify which parameters are relevant for each operation, relying on parameter names and enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Create and manage PBR materials in Blender.' It lists specific operations (e.g., create_fabric, create_metal) which clearly define the resource and actions. This differentiates it from sibling tools like blender_materials_baking (baking) and blender_shaders (shader editing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as blender_materials_baking or blender_shaders. It lacks explicit 'when-to-use', 'when-not-to-use', or references to other tools. The agent must infer context from the operation list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits such as side effects (e.g., whether baking overwrites existing textures), required Blender mode (e.g., requires an active scene), or error conditions. The description is limited to listing operations without deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. It lists operations efficiently without unnecessary text. It could be slightly more structured, but it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and parameter descriptions cover most fields, the description provides sufficient context for a texture management tool. It explains the key operational modes. However, it lacks details on return values or error handling, but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (88%), so parameters are mostly described in the schema. The description adds value by explaining the operation parameter's possible values (create_noise, create_voronoi, etc.) and listing assign/bake. However, it does not add meaning for parameters like width, height, or material_name beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates and manages textures in Blender, and lists specific operations (create procedural textures, assign, bake). It is specific about supported texture types. However, it doesn't differentiate from sibling tools like blender_materials or blender_shaders, which may overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists operations but provides no guidance on when to use each operation or how to choose between them. There is no comparison to alternatives. It lacks instructions on prerequisites (e.g., material must exist for assign) or context about typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It describes the pipeline (detect, convert, import) and mentions conversion tool selection, but fails to disclose important behaviors such as whether it modifies the current scene, creates new objects, handles errors, requires internet for some conversion tools, or has side effects like overwriting existing data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized (5 lines) with a clear front-loaded purpose and a structured list of pipeline steps. It is efficient but could be slightly more concise by removing redundancy (e.g., the pipeline list largely restates the opening sentence).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown in description), the description does not mention return values, success/failure indicators, or error handling. Given 8 parameters and no annotations, the description leaves significant gaps, such as what happens after import and how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add additional meaning beyond the schema; for example, 'filepath' is simply 'Path to CAD file' in both. No extra semantic context is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Import CAD files (STEP, IGES) into Blender with automatic conversion', specifying the verb (import), resource (CAD files), and target (Blender). It also outlines a clear three-step pipeline, distinguishing it from generic import tools like 'blender_import' by focusing on CAD-specific conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or compare with other import tools or sibling tools. While the purpose implies usage for CAD files, there is no direct advice for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions autonomous querying and pipeline building but discloses no side effects, state changes, permissions, or rate limits. The description is insufficient for understanding the tool's behavioral impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with no fluff. However, the first sentence's jargon reduces clarity, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, orchestrator role, no annotations), the description is too brief. It omits expected outputs (though output schema exists), failure modes, or examples, leaving significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no meaning beyond the schema; it does not explain the relationship between parameters or provide usage context for specific fields like 'available_operations'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it performs 'intelligent batch 3D scene processing' using 'multi-step sampling', which clearly identifies it as an orchestrator tool. However, it relies on jargon like 'FastMCP 3.1 SEP-1577' that may obscure understanding. It distinguishes from sibling tools focused on single Blender operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for complex, autonomous multi-step processing but does not explicitly state when to use this tool versus alternatives like blender_batch or simpler scripts. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so behavioral burden falls on description. It lists operations but doesn't disclose side effects, permissions, or safety considerations. Basic transparency but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and uses bullet points for operations, making it scannable. It could be slightly more structured with explicit sections, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 10 parameters and an output schema, the description is minimal. It doesn't cover prerequisites like needing an active scene or naming constraints, but is adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no extra meaning beyond the schema. It mentions operation types and lens settings, but these are already described in the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates and controls cameras in Blender, with specific operations listed. However, it doesn't differentiate from sibling tools that might also involve camera management, such as blender_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any preconditions or exclusions. The description only explains what the tool does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses multi-step sampling, probing capabilities, and graceful fallback, which are useful. However, it does not explain side effects, latency implications, or whether the tool modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence introduces purpose and method, and the second adds behavior. It could be more front-loaded with a clear action verb, but it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 100% schema coverage, the description is partially complete. It lacks explanation of output format, interaction with other tools, and example usage. The SEP-1577 reference is cryptic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are well-defined. The description adds context about multi-step sampling relating to max_steps, but does not expand on context_level enums. Overall, limited added value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a conversational Blender assistant with multi-step sampling, distinguishing it from specific operation tools. However, it lacks a clear verb-resource structure (e.g., 'answers Blender queries') and could be more explicit about its general-purpose role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for general Blender queries, mentioning probing capabilities and graceful fallback, but it provides no explicit when-to-use or when-not-to-use guidance. It does not reference sibling tools or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose side effects (e.g., whether the new scene becomes active) or any behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, one sentence front-loaded with action and resource, no wasted words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, the description is mostly complete but lacks behavioral nuance about active scene state and return value context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only adds 'with the specified name' for the single parameter, but schema coverage is 0%, so more detail is expected. Minimal additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and resource 'a new Blender scene', clearly distinguishing it from siblings like 'set_active_scene' or 'clear_scene'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like switching scenes or clearing a scene, and no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes the general workflow (natural language to Python script execution, validation for modify) but lacks details on side effects (e.g., scene changes, script storage, failure modes) and does not mention that this is a destructive operation by nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for each operation and a client requirement note. It is somewhat verbose (e.g., listing supported clients) but front-loaded with the core purpose. A minor improvement would be to remove the client list or move it to a separate context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters, no schema descriptions, and output schema exists but is not described, the description is incomplete. It fails to explain return values, error scenarios, or how the AI sampling integrates with the parameters. The tool's complexity demands more thorough documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only hints at 'description' and 'object_name' through the operation explanations, leaving 10 out of 12 parameters undocumented. Parameters like 'complexity', 'style_preset', 'allow_modifications' are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for 'AI-powered object construction and modification via sampling' and lists three distinct operations (construct, construct_and_save, modify). This verb+resource specification differentiates it from sibling tools like 'construct_object' which is likely simpler.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'construct_object' or other blender tools. It mentions a client requirement (MCP sampling) but does not explain contexts for each operation or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only mentions destructiveness for 'clear_animation' but lacks details on side effects, permissions, undo behavior, or performance. This is insufficient for a complex tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with categories and bullet points, but it is verbose, especially the portmanteau rationale. It could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (32 parameters, 21 operations), the description covers categories and operations adequately. However, it omits output schema details and error handling, though an output schema exists. Somewhat incomplete but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds grouping by category and some context (e.g., which operations require which parameters), but the incremental value is modest. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Comprehensive animation system for Blender' and lists all categories and operations. The tool name 'blender_animation' directly indicates its domain, and the detailed breakdown distinguishes it from sibling tools like blender_mesh or blender_transform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives like blender_shapekeys or blender_rigging. While the categorization helps, there is no guidance on use cases or when not to use certain operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear the full burden. It lists operations but does not disclose behavioral traits such as side effects, error conditions, or whether modifications are permanent. The description is minimal in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, using a list format for operations. However, the list is embedded in a paragraph rather than separated, and some entries are terse. It avoids extraneous information but could be better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity with 12 parameters and the presence of an output schema (unseen), the description lacks completeness. It does not explain return values, operation order, or when certain parameters are applicable. For a sculpt tool, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 12 parameters with 0% description coverage. The description adds meaning by linking some parameters (e.g., brush_name, strength, radius) to operations, but many parameters (like object_name, detail_resolution) are not explained. It provides partial value but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool handles sculpt mode operations for organic mesh editing. It lists specific operations like enter, exit, set_brush, dynotopo, etc., which distinguishes it from sibling tools such as `blender_mesh` or `blender_modifiers`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for sculpting tasks through the listed operations but does not explicitly state when to use this tool over alternatives. No guidance on prerequisites or when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects (e.g., apply_transform being destructive), authorization needs, or rate limits. It only lists operations without addressing safety or mutation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and uses a well-structured bulleted list for operations. It is concise without extraneous text, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 13 parameters and an output schema, the description lacks crucial context on parameter interactions (e.g., required params per operation) and does not explain coordinate spaces or relative flag behavior. This leaves significant gaps for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 31%, but the description adds value by enumerating operation types. However, it fails to clarify which parameters are used for each operation (e.g., x/y/z for set_location) and does not fully compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool transforms objects in 3D space and explicitly lists all supported operations (set_location, set_rotation, etc.). It distinguishes from sibling tools by its specific focus on transformations, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests use for 3D object transforms but lacks explicit guidance on when to use this tool vs alternatives (e.g., translate vs set_location). No exclusionary language or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the key operations (capture PNG+base64, review multi-angle bundle, apply script) and the refinement cycle. However, it lacks details on error handling, permissions, or return value format, leaving some behavioral aspects uncovered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and uses bullet points to list operations, making it easy to scan. The key purpose is front-loaded. However, the term 'Agent vision refinement loop' may be jargon, and the structure could be slightly more straightforward.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters with 0% schema description coverage and an output schema (content unknown), the description does not adequately explain the parameters. It only covers operations partially. The description is not complete for this complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions for 9 parameters). The description only loosely references 'operation' and 'output_path' but does not explain parameters like goal, script, resolution_x, resolution_y, include_multi_angle, angles, or output_dir. It adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an 'Agent vision refinement loop' and lists three specific operations (capture, review_bundle, apply_script). It distinguishes itself from siblings by focusing on vision-based iterative refinement. However, the title is null, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for iterative vision refinement, but it does not explicitly state when to use it versus alternatives like blender_ai_generate or intelligent_3d_processing. No when-not-to-use guidance or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It details a 6-step agentic workflow, mentions validation and safe execution, and notes iteration. However, it does not address prerequisites, destructive potential (parameter allow_modifications exists but not emphasized in behavior), or error states beyond iteration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is overly verbose, opening with a non-user-facing 'PORTMANTEAU PATTERN RATIONALE' that should be removed. While structured with sections, many sentences are self-promotional and could be trimmed significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, no annotations), the description covers purpose, workflow, complexity levels, and style presets. The existence of an output schema reduces need for return details, though some information on handling failures and output format is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about how parameters like 'description' are used in sampling, but largely repeats schema defaults. No contradiction but limited added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it constructs 3D objects from natural language via LLM scripts. It distinguishes itself from many specialized Blender tools by being a universal interface, though it does not explicitly compare to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for high-level creation from description, but lacks explicit guidance on when to use this vs. other Blender tools (e.g., blender_mesh, blender_ai_generate). Complexity levels and style presets offer some context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It only says 'merging materials and textures', without disclosing side effects, destructive actions, or what gets modified. Important details like whether it alters existing materials or creates new assets are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the core purpose and key benefit (VR optimization, draw call reduction). No extraneous words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 11 parameters and an output schema, the description is too brief. It does not explain the workflow, how different operations relate, or what the expected output is. Important context about prerequisites or typical usage scenarios is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no meaningful information about parameters beyond what the schema already provides. It does not explain parameter interactions or usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Advanced material and texture atlasing for VR performance optimization' and 'reduces draw calls'. It names specific operations in the schema, making it distinct from sibling tools like blender_materials or blender_textures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at usage for mobile VR ('critical for mobile VR performance on Quest'), but does not explicitly exclude alternative tools or provide guidance on when to use this vs. baking or manual UV mapping. It lacks clear when/not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It briefly describes each operation but omits side effects, prerequisites, permissions, or destructive behaviors (e.g., delete_strokes just says 'remove strokes' without detail).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a rationale then bullet list, making it scannable. It is relatively concise given the scope, though a bit long but each part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 operations, 27 parameters) and an existing output schema, the description covers the operations at a high level. However, it lacks behavioral context and usage scenarios, so it is not fully complete for an agent to invoke correctly without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description groups parameters by operation (e.g., 'used by: draw_stroke') which adds marginal context, but does not provide deeper semantic meaning beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it consolidates 12 Grease Pencil operations and lists each with a brief definition. It distinguishes itself from other Blender tools by focusing specifically on 2D animation with Grease Pencil.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists operations but provides no explicit guidance on when to use this tool versus sibling tools (e.g., blender_mesh, blender_modifiers). Usage is implied by the operation context, but no 'when not to use' or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions asynchronous execution, immediate job_id return for submit, and the ability to cancel, but it does not describe persistence, error handling, side effects of cancelling, or whether jobs survive a restart. This leaves significant gaps for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single opening line defining the tool's purpose, followed by a bulleted list of operations. Every sentence is necessary and front-loaded, making it easy to scan. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, multiple operations, and the presence of an output schema), the description provides a high-level overview but lacks details on parameter usage, output format, and error scenarios. It is adequate for a first glance but not fully complete for safe invocation without further exploration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with 0% description coverage, meaning the description does not detail them. While the description hints at job_id and script usage in the operations list, it fails to explain the meaning of parameters like timeout, prefer_session, and limit, or how they affect behavior. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Async job queue for long-running Blender Python scripts' and lists four operations (submit, status, list, cancel) with clear actions and return behavior. This distinguishes it from other Blender tools like script_execute or blender_render, which handle immediate execution or rendering, not async job management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use each operation (e.g., submit for long scripts, status to check progress), but it does not provide explicit guidance on when not to use this tool or compare it to alternatives such as blender_render (which might handle renders synchronously). The usage context is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes operations but fails to disclose behavioral traits such as side effects of applying/removing modifiers, undo behavior, or error conditions. For a 12-parameter tool, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bullet list of operations and clear grouping. It is slightly verbose with repeated 'Add' prefixes, but front-loads the main purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters and no annotations, the description covers operations but lacks contextual guidance on when to choose specific modifiers or how parameters interact. An output schema exists but is not shown, which could have compensated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by grouping operations and listing per-modifier parameters, but does not significantly augment the parameter descriptions already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Apply and manage mesh modifiers in Blender' and lists all supported operations with examples, making its purpose distinct from sibling tools like blender_mesh or blender_materials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists operations but does not explicitly guide when to use this tool versus alternatives like blender_mesh or blender_transform. Usage is implied through the tool's name and operation list, but no exclusions or when-not-to-use guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions creation and management (mutations) but does not disclose side effects, required permissions, or resource implications (e.g., baking may be compute-intensive). No behavioral traits beyond the operation list are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear bullet list of operations. It front-loads the general purpose and then enumerates operations efficiently. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 params and 7 operations, the description covers the operation names but misses parameter-operation mapping and expected outputs (though output schema exists). It is adequate but not comprehensive for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have descriptions in the schema (100% coverage), so baseline is 3. The description lists operations but adds no semantic context about how parameters interact with operations or constraints (e.g., which params apply to which op).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates and manages particle systems, listing 7 specific operations. This verb+resource scope distinguishes it from sibling tools like blender_physics or blender_animation, which handle broader physics or animation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for particle effects but provides no explicit guidance on when to use this tool versus alternatives like blender_physics or blender_mesh. No when-not conditions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention that the tool is read-only, what authentication is needed, or any side effects. The operations are listed but not described in terms of impact, leaving the agent uncertain about safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief introductory sentence and a bullet list of operations. It is concise and front-loaded, though the term 'portmanteau' is unnecessary and could confuse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. However, with 7 parameters and no usage examples, the description is adequate but not rich. Missing details like rate limits or performance implications for the monitoring operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (86%), so the baseline is 3. The description adds little beyond the schema, merely repeating operation options without additional context like format examples or default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('status', 'system_info', 'health_check', 'performance_monitor') and clearly identifies the resource as system status and monitoring. It distinguishes from sibling tools by focusing on non-Blender operational monitoring, which is unique among the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description lists operations and parameters, it provides no explicit guidance on when to use this tool versus alternatives. Given the large number of sibling tools, the lack of contextual usage advice limits clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only states the action without mentioning reversibility, impact on other scene elements, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and target, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool with no parameters and an output schema. Provides the core action, though could mention what is not removed (e.g., collections).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist and schema coverage is 100%, so baseline is 3. Description adds minimal value beyond the schema, only clarifying 'current scene' scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Remove all objects from the current scene', using a specific verb and resource. It uniquely identifies the tool's action among siblings like add_to_collection or create_scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., selective deletion or clearing a different scene). Context on prerequisites or side effects is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description merely says 'discover' implying a read operation, but does not disclose any behavioral traits such as rate limits or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence, front-loaded, but slightly under-specified; still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, description lacks details about return format; adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies; description adds no parameter info but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers local LLM models from Ollama and LM Studio, using a specific verb and resource, distinguishing it from siblings like llm_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like llm_models; lacks when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: save exports to a specific path with metadata, load appends with optional transforms, search filters by query/category/tags/quality. However, it does not detail side effects (e.g., overwrite behavior, permission requirements) or handling of edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (7 lines) with a clear summary line and bullet-point breakdown of operations. It is front-loaded and efficient, though the first line 'Object repository management' slightly overlaps with the subsequent detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 18 parameters, no annotations, and no schema descriptions. The description explains only a fraction of these parameters and does not cover important fields like version, author, quality_rating, etc. Given the parameter richness, the description is significantly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially explains parameters related to operations (query, category, tags, quality for search) but does not cover many others like object_name, version, author, min_quality, complexity, limit, quality_rating, public. The description adds limited value beyond listing parameters in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: managing an object repository with four specific operations (save, load, search, list_objects). It distinguishes itself from sibling tools like manage_asset_library by specifying the repository location (~/.blender-mcp/repository/) and the actions involved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage scenarios by listing operations (e.g., export vs. append), but it does not explicitly state when to use this tool over alternatives like blend_export or manage_asset_library. No when-not or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It fails to mention side effects like object modification, scene changes, or dependencies. The description only states what the tool does, not how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It uses a bulleted list for operations, making it scannable. Every sentence is functional, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has 10 parameters and no required fields, the description adequately explains the tool's purpose but does not cover when specific operations should be used or how they interact. The presence of an output schema reduces the need to describe return values, but the description still lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 parameters. The description adds value by listing operations but does not elaborate on parameter usage beyond what is in the schema. Thus, baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Enable and configure physics simulations for objects.' It lists specific operations (e.g., enable_rigid_body, enable_cloth), making the tool's purpose unambiguous and distinct from sibling tools like blender_rigging or blender_animation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists supported operations, providing some usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it include when-not-to-use guidance. The context is implied but not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It discloses the supported operations but does not explain behavioral traits such as how the mode parameter affects selection (REPLACE, ADD, SUBTRACT) or what happens to existing selection. The description adds partial context but lacks crucial details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph listing operations in a bullet-like format, which is concise and readable. It front-loads the main purpose. However, it could be slightly more structured (e.g., using a list) for clarity, keeping the score at 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered elsewhere. The description enumerates operations and implies corresponding parameters. While it misses some nuance (e.g., how active_object interacts), it is largely complete for a selection tool with well-documented parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description adds value by mapping operations to parameters (e.g., select_objects uses object_names), but this is only marginal beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool selects objects and elements in Blender scenes, and lists several specific operations (select_objects, select_by_type, etc.), making the purpose crystal clear. The tool is distinct from any sibling tool, as no other sibling has 'selection' in its name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it explain when to prefer one operation over another. The operations are listed, but without context or exclusions, the agent must infer usage from parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. It mentions the 'download' operation requires a URL and optionally imports, but omits details such as side effects (e.g., file creation), network behavior, error handling, or permission requirements. The tool's mutability and potential impacts are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured, using a top-level summary and bullet-points for operations. Every sentence adds value, with no extraneous text. It is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (two operations, 5 parameters) and the existence of an output schema, the description covers the core functionality. It explains the two operations and provides a hint about each. However, it could elaborate on the 'info' operation's return structure or usage recommendations for different parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds that the 'url' parameter is 'required' for download and that 'info' provides supported formats, but these details are largely redundant with the schema. No additional semantic meaning beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's two main operations: downloading from a URL and optionally importing into the scene, and getting supported format info. It uses specific verbs and resources, distinguishing it from sibling tools like blender_import or blender_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description outlines the two operations ('download' and 'info') and notes that 'download' requires a URL. However, it does not explicitly state when to use this tool versus alternatives like blender_import or blender_mesh, nor does it mention cases where the 'info' operation is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It mentions handling scale, format, and bone limits, but does not disclose whether the tool modifies the scene, requires permissions, or has side effects. Adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, highly concise, front-loaded with the main purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too high-level for a tool with 13 parameters and multiple operations (export, validate, get presets, create custom). It does not mention the different operation types or provide enough context for the agent to understand the full scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description does not add additional meaning beyond the schema for individual parameters, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides platform-specific export presets for VR avatar deployment, explicitly naming VRChat, Resonite, and Unity. It distinguishes from the sibling 'blender_export' by focusing on platform-specific presets rather than general export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for VR avatar deployment with platform-specific adjustments, but it does not explicitly state when to use this vs alternatives like 'blender_export'. No when-not-to or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states conversion and a high-level purpose, without detailing operations, side effects (e.g., new textures or modifications), or prerequisites like Blender add-ons. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The core action is stated first, followed by essential context. It is highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 10 parameters and multiple operations, the description is too brief. It lacks explanation of operation types, workflow steps, or dependencies. For a complex tool, this under-specifies how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter descriptions. It does not clarify operation types or parameter interactions, but this is acceptable given schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts non-standard VRM/MToon shaders to PBR textures, providing a specific verb and resource. It distinguishes from sibling material tools by focusing on VRM avatar use cases, avoiding ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for VRM avatars moving to PBR environments and mentions 'Semantic Dilution', but lacks explicit when-to-use vs alternatives or when-not-to-use guidance. Still, the context is clear enough for an agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like side effects, permissions, or limitations. It only states it is an alias, but does not explain the behavior of individual operations or any constraints. The agent is left to infer behavioral details from the parent tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences. The first sentence front-loads the most critical information (compatibility alias, prefer other tool). Every word serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no required ones, the description lacks details on how to use each operation with the parameters. Despite having an output schema, it doesn't mention return values or error handling. The description relies heavily on the agent knowing the parent tool, leaving a significant gap in standalone completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description lists the possible operations (search, install_known, etc.), which adds meaning to the 'operation' parameter. However, it does not explicitly map parameters like 'query' or 'addon_name' to specific operations, so the mapping is only implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as managing Blender addons and lists operations (search, install, etc.). It also states it is a compatibility alias, which clarifies its role relative to blender_addons. However, it does not elaborate on what each operation does, but the purpose is sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'compatibility alias — prefer blender_addons', giving clear guidance to prefer the alternative tool unless compatibility is needed. It also states that operations mirror blender_addons, so the agent knows where to find details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only describes the output format but does not disclose any behavioral traits such as performance impact for large scenes, read-only nature, or required permissions. The tool name implies reading, but transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that captures the essence without any wasted words. It is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema likely exists (context signals indicate so), the description provides sufficient context for a simple retrieval tool. It could be improved by clarifying what 'full scene hierarchy' includes (e.g., nested objects, transforms), but it is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is trivially 100%. Per guidelines, the baseline is 4 for zero parameters, and the description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full scene hierarchy', and specifies the output format as a JSON-formatted string. This distinctly differentiates it from sibling tools like 'list_scenes' which likely returns only scene names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternative tools like 'list_scenes', 'create_scene', or other scene-related tools. There is no context about appropriate usage or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It lists operations and their effects (e.g., light creation, modification) but does not describe side effects like scene modification, undo implications, or permission requirements. It is transparent about what each operation does but lacks depth on behavioral side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary and categorized bullet points, making it easy to parse. However, it includes a lengthy 'PORTMANTEAU PATTERN RATIONALE' that is meta and not directly helpful for using the tool. A slightly more concise version would earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, 7 operations) and lack of annotations, the description covers all operations and their parameters comprehensively. It explains defaults, ranges, and usage for each operation. The presence of an output schema (not shown) suggests return values are handled elsewhere, keeping the description focused on inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond what is already in the parameter descriptions. It groups parameters per operation but does not provide new semantics or constraints. The baseline of 3 is appropriate as the description is not essential for understanding the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a professional lighting system for Blender supporting all light types and lighting setups. It lists specific operations (create_sun, create_point, etc.) and distinguishes itself from sibling tools like blender_render or blender_materials by focusing exclusively on lighting workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly tell the agent when to use this tool versus alternatives. There is no mention of when not to use it or guidance on choosing between the individual operations within the tool. It relies on the agent inferring that this is the go-to for all lighting tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, permissions, or destructive actions. It only describes operations list without safety or impact details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Despite length, the description is well-structured with headers, bullet points, and front-loaded rationale. Every section adds value for a complex tool with 11 operations and 25 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers operations and parameters but lacks guidance on prerequisites, return values, or behavioral context. Given the complexity and presence of output schema, completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters by operation and providing brief explanations, which helps contextualize parameter usage beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Complete character rigging system for Blender' and lists all 11 operations grouped into categories. It differentiates from sibling tools by focusing specifically on rigging, not animation, mesh, or other domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for rigging tasks but does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools like blender_animation or blender_mesh. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source. It discloses that stop kills the process, that start can open .blend files, and that scripts need the bridge addon. However, it lacks details on side effects (e.g., unsaved work on stop, read-only nature of status) and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using a bullet list for operations. Every sentence adds value, and the most important information (purpose and operations) is front-loaded. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of managing a session with five operations, the description covers the basics but omits details about return values (status output, script results) and error scenarios. An output schema exists but is not shown; still, the description could be more complete regarding expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning, mostly repeating schema descriptions. It does link operations to relevant parameters (e.g., 'for start — path to a .blend file'), but does not explain format or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages a Blender GUI session and enumerates five specific operations (status, start, stop, run_script, demo). This provides a specific verb-resource mapping and differentiates from sibling tools by focusing on session lifecycle rather than scene editing or rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that run_script requires the bridge addon, giving a prerequisite. However, it does not explain when to use this tool versus alternatives like script_execute or blender_status. No explicit 'when-not' or context for choosing among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool uses external backends, requires API keys, and performs a multi-step process (poll, download, import). Since no annotations are provided, the description carries the burden. However, it lacks details on error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two paragraphs and front-loads the main purpose. It could benefit from more structured formatting (e.g., bullet points for parameters), but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 3 backends, 2 operations) and no output schema shown, the description is incomplete. It fails to cover parameter details and return values, leaving gaps for effective agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with 0% description coverage. The description only mentions operations and backends but does not explain key parameters like prompt, image_path, object_name, output_format, or poll_timeout, leaving the agent uninformed about their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates 3D meshes via external AI backends and imports into Blender, with specific operations (generate, list_backends) and backends (tripo, rodin, hunyuan). It is distinct from siblings like blender_mesh or blender_render, which handle different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool: for AI-generated 3D content, and mentions prerequisite API keys. It does not explicitly exclude other scenarios or compare to siblings, but the context is adequate for most users.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it writes to a temp directory and returns paths, and mentions file paths must exist. However, it does not disclose whether it modifies the repository or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences plus a list of supported targets and a prerequisite. It front-loads the core action. Very minor room for improvement by adding minor structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters with no schema descriptions, no annotations, and an output schema, the description is incomplete. It does not explain the output, optimization options, or metadata flag, leaving agents with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It only mentions asset_id and target_mcp implicitly, but does not explain optimization_preset, quality_level, or include_metadata. The description adds little value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exports a repository asset with platform-specific optimizations for cross-MCP handoff, listing supported targets (vrchat with FBX, resonite with GLB). This differentiates it from generic export tools like 'blender_export' among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies supported targets and prerequisite (asset_id must exist in repository), but does not explicitly state when to use this tool over alternatives or when not to use it. Some guidance is provided, but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description mentions that pull is slow and remove deletes from disk, but lacks details on side effects, authentication needs, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured with bullet points, and front-loaded with the core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter documentation, the description covers operations, mentions LM Studio reachability, and notes performance. Lacks prerequisites or error handling, but sufficient for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add significant meaning beyond what is already in the schema descriptions. It provides example model names but that is also present in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs list, pull, or remove operations on Ollama models, with a concise 'Portmanteau' label. It distinguishes from sibling tools like list_local_models by covering additional operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for managing Ollama models but does not explicitly state when to use this tool over alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only mentions that 'list_installed' requires Blender, but fails to specify prerequisites, side effects (e.g., enabling/disabling modifies Blender state), or authorization needs for install/uninstall operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear statement of purpose and a concise list of operations. Every sentence serves a purpose, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers all operations, it lacks detail on error handling, return values (though an output schema exists), and consistent prerequisites (only 'list_installed' mentions 'requires Blender'). It is adequate but not comprehensive for a tool with six parameters and multiple operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds some value by mapping operations to parameters (e.g., 'install_addon: Install from local addon_path'), but does not provide significant additional meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Manage Blender addons' and lists all operations, making the purpose explicit. It also distinguishes from the sibling tool 'manage_blender_addons' by claiming preference, which helps an agent choose correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Prefer this tool over manage_blender_addons', providing direct guidance on when to use this tool versus a sibling. The list of operations further clarifies the scope of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains supported operations, CAD conversion, and mesh quality control, but it omits side effects (e.g., does it clear existing imports?, impact on scene objects) and potential limitations like performance impact or file size constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections for general operations and CAD features, making it easy to scan. It is front-loaded with the main purpose. Slightly verbose due to repeated details (e.g., CAD conversion list), but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, high schema coverage, and an output schema, the description is fairly complete. It covers all major operations and CAD-specific behavior. Minor gaps: no mention of return value format or scene interaction (e.g., does it report success/failure?).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (90%), so baseline is 3. The description adds context for the 'operation' parameter by listing its variants and describes CAD-specific parameters (cad_conversion_tool, mesh_quality). However, it does not elaborate on parameters like 'use_custom_normals' or 'import_shading' beyond the schema, and some parameters (asset_name) lack description in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the tool's purpose: importing 3D files into Blender. It specifies supported operations (import_[format], import_cad, link_asset) and lists formats (FBX, OBJ, GLTF, CAD), distinguishing it from siblings like blender_export and import_cad_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context on when to use different operations (import_[format], import_cad, link_asset) and highlights CAD conversion features. However, it does not explicitly state when not to use this tool or name alternative tools for specific cases (e.g., using import_cad_file separately), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description implies read-only behavior but doesn't explicitly state safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with clear operation breakdown, though the word 'portmanteau' is unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately covers the tool's functionality and parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps parameters to specific operations, adding value beyond the schema's per-parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool views logs or gets buffer statistics, distinguishing it from sibling tools that focus on 3D operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, but the operations are self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the supported operations and their brief purposes (e.g., 'unwrap UV coordinates') but does not mention side effects, reversibility, or failure modes. Without annotations, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and uses a bullet list for operations. It is structured logically but could be slightly more compact. Still, it achieves clarity without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 4 parameters (all documented), an output schema (mentioned in context), and straightforward operations, the description is largely complete. It covers the main functionality and operation options. Minor gaps include lack of prerequisite info (e.g., object must have mesh) but overall adequate for typical UV tasks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, so the description does not need to repeat parameter details. However, it adds value by enumerating valid operation values and their meanings, which goes beyond the schema's 'UV operation type' description. For other parameters like unwrap_method and margin, the schema descriptions suffice. Overall, the description provides incremental meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages UV mapping and texture coordinates, and lists specific operations (unwrap, smart_project, etc.). This verb+resource pairing is specific and distinguishes from sibling tools like blender_mesh, blender_textures, etc., which handle other aspects of 3D modeling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for UV-related tasks but does not explicitly state when to use it versus alternatives or provide exclusions. It lists operations but offers no guidance on selecting between them, e.g., when to use unwrap vs smart_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only listing but does not disclose edge cases or absence of side effects. The minimal description provides adequate transparency for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown but noted), the description does not need to explain return values. For a zero-parameter tool, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description adds no parameter info, which is appropriate given the empty schema and 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and resource (scenes) with a specific scope (current Blender file). It distinguishes from sibling tools like 'create_scene' and 'clear_scene'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it returns information, implying no side effects, but does not disclose potential behaviors like authentication needs or what happens if server is unavailable. Minimal but adequate for a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key action and output. No wasted words. Ideal length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While output schema likely details return structure, the description could provide a bit more context on what 'information' includes (e.g., version string, status flags). Simple tool, but slightly under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description does not add param semantics but is not required. Baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Return Blender MCP server information, version, and status,' which clearly identifies the tool's purpose and resource (server info). It distinguishes from sibling tools focused on Blender operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, as a simple info tool, usage is self-evident for checking server status or version, but lacks when-not-to-use or exclusion details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It describes a non-destructive lookup, but doesn't detail how search works, return format, or potential limitations like offline use. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, examples, usage advice. No redundant or missing words. Efficiently conveys everything needed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers core use and context. It doesn't detail search behavior or error handling, but output schema likely covers return values. Minor omissions but largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description gives examples for identifier and hints at usage. The search parameter is not explained. With zero schema descriptions, the description partially compensates but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool looks up Blender Python API documentation for an identifier, with concrete examples (Mesh, bpy.types.Mesh). It distinguishes from siblings like blender_help which might be more general.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using before writing bpy scripts to avoid hallucinated API calls, providing clear context. However, no information on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It comprehensively lists all 20 operations and their effects, such as adding strips, trimming, muting, and rendering. However, it does not disclose side effects (e.g., whether operations modify current Blender state or are undoable). Given the extensive operation listing, it is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear categories and operation lists, which aids readability. However, the first paragraph about 'PORTMANTEAU PATTERN RATIONALE' is somewhat verbose for an AI agent and could be condensed. Overall, it is well-organized and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (40 parameters, 20 operations), the description is comprehensive. It covers all operation categories and indicates which parameters are needed for each. The output schema exists but is not detailed here; still, the description provides sufficient context for use. Minor gaps exist, such as missing error handling or state constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 78% description coverage, so the baseline is 3. The description adds value by mapping operations to required parameters (e.g., 'Required for: add_movie, add_sound' for filepath). It also groups operations, enhancing understanding of which parameters are relevant for each task. This goes beyond the schema's individual property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool consolidates 20 VSE operations into a single interface for video editing. It lists all operations in categories (strip creation, editing, properties, etc.) and explicitly mentions capabilities like strip management, timeline editing, effects, and rendering. This distinguishes it from sibling tools that focus on other Blender domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a rationale for the portmanteau pattern but does not explicitly guide when to use this tool versus alternatives. There is no mention of prerequisites, when not to use, or how to choose among the 20 operations. The categorized list of operations gives some implicit guidance, but no clear usage rules are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation ('Return current webapp config'), but with no annotations, it lacks details on permissions, side effects, or response format. Adequate for a simple read but minimal beyond verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, concise sentence that immediately conveys the purpose. No wasted words, front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (documenting return values) and zero parameters, the description provides sufficient context about the config contents. Complete for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description correctly adds no parameter info since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the current webapp config with specific examples (LLM provider, URLs, selected model), distinguishing it from sibling tools like config_set (write) and server_info (server-level).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or not use this tool, but the context of a simple getter with zero parameters makes its usage obvious. No mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the iterative, autonomous nature and max_steps limit, but omits potential side effects (e.g., scene modifications) or what 'capability probes' entail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding essential information: technology, process, and constraints. No redundancy; front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and full parameter descriptions, the tool is well-covered. However, it could be improved by clarifying its relationship to similar workflow tools like 'blender_workflow' and 'intelligent_3d_processing'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for parameters. The description adds context by explaining the workflow_prompt as a natural language goal and highlighting the tool's autonomous probing behavior, which enriches the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes 'autonomous multi-step Blender workflows' via FastMCP sampling. It differentiates from siblings like 'blender_workflow' by emphasizing autonomy and looping behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to invoke the tool: for complex goals requiring step-by-step LLM planning. It implicitly excludes simpler operations but lacks explicit 'when not to use' or alternative tools like 'intelligent_3d_processing'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It details sequential execution, optional variable passing, step dependencies (if_result), and stop_on_error behavior. It lacks specifics on error handling beyond stopping, but overall provides significant behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (overview, operations, step format, variable references) and front-loaded purpose. It is slightly lengthy but each sentence adds value; could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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, 3 operations, conditional logic), the description is quite complete. It explains step sequencing, variable references, and operation behavior. It does not provide examples or clarify return values, but an output schema exists. Adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the 100% schema-covered parameters. It explains step format, variable reference syntax, operation roles (e.g., template usage), and conditional execution, which are not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute multiple Blender operations in a single call (macro/batch).' It lists operations (list_templates, get_template, execute) and differentiates from single-operation siblings by enabling complex workflows without multiple round-trips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-step workflows needing sequential execution and variable passing, avoiding round-trips. However, it does not explicitly exclude cases where single-operation tools are preferred or compare with the sibling 'agentic_blender_workflow'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: use of a fleet subprocess Blender, environment variable dependencies, that HDRIs set world environment, and that Sketchfab imports require downloadable models. Missing details on error handling or rate limits, but still above average.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a portmanteau label and a bulleted list of operations. Every sentence conveys necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 13 parameters and 6 operations, the description covers each operation's purpose, prerequisites, and parameter hints. The existence of an output schema reduces the need for return value explanation. Minor gaps exist (e.g., pagination details for Poly Haven search), but overall it's comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context by grouping parameters under operations (e.g., 'polyhaven_import: Download + import...'). This clarifies how parameters interact beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool covers 'Poly Haven + Sketchfab asset discovery and import' and lists six operations with clear verbs. It distinguishes from sibling tools (e.g., blender_import, list_local_models) by focusing on external asset libraries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides operational details and prerequisites (e.g., env vars for Sketchfab, token requirements for imports). It implicitly guides when to use each operation, but lacks explicit comparisons to siblings or 'when not to use' conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fully describes each operation and their parameters, making the tool's behavior transparent. It is a read-only informational tool, so no destructive actions are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief overview sentence followed by a bullet list of operations. Every sentence provides valuable information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 6 parameters and 5 operations, the description is complete. It covers all operations and parameter mappings. An output schema exists (from context), so return values need no explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning by mapping each parameter to specific operations (e.g., function_name for help, query for search), enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides help, lists tools, searches, gives tool info, or shows categories. It uses specific verbs and resources, distinguishing it from other Blender tools which are specialized for particular tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists operations with parameters and their purposes, giving clear context for each. It does not explicitly state when not to use or provide alternatives, but as a help tool, the usage is well-implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![blender-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/blender-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sandraschi/blender-mcp)

Score Badge

Copy to your README.md:

[![blender-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/blender-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sandraschi/blender-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sandraschi/blender-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server