mcp-3d-modeling-agent
Server Quality Checklist
Latest release: v0.4.0
- Disambiguation2/5
The set contains several near-duplicate tools that make agent selection hard: blender_refine_iteration and blender_ai_refine both describe the same render-evaluate-suggest loop, and blender_ai_list_backends overlaps heavily with blender_ai_probe_backends. Many workflows also have two parallel implementations (e.g., blender_scatter_on_surface vs blender_geonode_scatter_instances), so boundaries are often unclear even when individual descriptions are good.
Naming Consistency4/5Most tools follow a clear blender_<domain>_<action> or blender_<domain>_<noun> snake_case pattern, which makes large chunks like blender_object_*, blender_mesh_*, and blender_msfs_* predictable. Deviations exist (blender_undo, blender_save, blender_silhouette_compare, blender_mesh_proportional_transform, blender_sculpt_to_retopo), but they are few compared to the 218-tool surface.
Tool Count1/5218 tools is an extreme count for any MCP server, far beyond the threshold where a toolset becomes unwieldy. The surface tries to cover entire Blender plus MSFS and AI pipelines in one server, making discovery and selection expensive for agents.
Completeness4/5The domain coverage is impressively broad: object/scene lifecycle, mesh editing, materials, animation, rendering, physics, rigging, sculpting, baking, geometry nodes, and MSFS-specific workflows are all present. Minor gaps exist (no material_delete, no constraint_remove, no individual object visibility toggle, no render samples/output settings), but agents can often work around them via blender_execute_script.
Average 3.5/5 across 201 of 218 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto 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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description gives no information about side effects, such as whether the material must exist, whether the shader node is created if missing, or what happens if parameters are invalid. With no annotations, the description carries the full burden and fails to disclose any 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, which is appropriate for the tool's purpose. However, it could be slightly expanded to include usage context without becoming verbose, so it's not perfectly balanced.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema, the description is too sparse. It lacks details about how the parameters interact, whether the material must be selected or named, and what the expected outcome is. This leaves the agent without enough context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), but the tool description adds no additional meaning. It does not explain parameter relationships, defaults, or which parameters are required beyond the schema's required field. Since schema coverage is high, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Configure' and a specific resource 'Principled BSDF shader parameters', making it clear that this tool adjusts PBR material settings. However, it could be more explicit about the scope compared to other material tools like set_color or add_texture, so it's not fully distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 over alternatives such as blender_material_set_color or blender_material_add_texture. It does not mention prerequisites like an existing material or the presence of a Principled BSDF node.
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 disclosure burden, but it only says 'Configure modifier parameters' and offers no detail about side effects, prerequisites, or whether changes are applied to an existing modifier. This is insufficient behavioral transparency for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded, but it largely restates the tool name and lacks the substance needed to be useful. This reads as under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and schema-documented, but without annotations, an output schema, or usage context the description leaves an agent unsure what properties are valid, whether the modifier must already exist, and what happens after configuration. The one-line description is not complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema fully documents object_name and modifier_name and gives an example for properties. The description adds no parameter-level meaning, but the baseline of 3 applies because the schema covers the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action, configuring modifier parameters, on a specific resource, modifiers. It is distinguishable from sibling modifier tools like blender_modifier_add/remove/apply by implying an existing modifier's parameters are being changed, though it does not explicitly state that.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus blender_modifier_add, blender_modifier_apply, or blender_modifier_remove. The intended context, modifying an already-added modifier, is only implied by the tool's name and sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it fails to carry it. 'Duplicate an object' does not state whether the original is modified, where the duplicate is placed, how auto-naming works, or what consequences the linked parameter has on scene behavior. 'Duplicate' weakly implies a non-destructive copy, but nothing is explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words with zero waste and is front-loaded. However, this is under-specification rather than effective conciseness — it essentially restates the tool's name without contributing additional decision-making value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with behavioral nuance (linked vs. independent duplication) and no output schema or annotations, the description is incomplete. Key gaps include naming conventions, placement of the duplicate, and when linked mode is appropriate. The 100% schema coverage mitigates parameter ambiguity but not the behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The schema already documents all three parameters adequately, including the linked boolean ('Create a linked duplicate (shares mesh data)'). The description itself adds no parameter-level meaning, but the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Duplicate') and resource ('an object'), which is distinct enough from sibling tools like blender_object_create, blender_object_delete, and blender_object_transform. However, it adds little beyond the tool name itself and does not clarify the scope of duplication (e.g., whether child objects or modifiers are included).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of when a linked duplicate is preferable to an independent copy, nor any distinction from blender_object_create or blender_collection_instance. The agent is left to infer usage context entirely.
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 disclosure burden. 'Download and apply' implies a network operation that mutates the Blender scene, but it does not mention licensing, download time/size, object/material selection side effects, undo behavior, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, which is good for scanability. However, it is sparse enough that it mostly restates the tool name plus 'apply' and does not enrich the agent's understanding much beyond the name itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, this description is too thin for a tool that downloads and applies external assets. It omits the workflow connection to blender_polyhaven_search, asset-type behavior, and practical expectations like network access or scene impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 schema already documents asset_id, apply_to, and resolution. The description adds no extra parameter-level meaning, such as which asset types require apply_to or how resolution interacts with asset type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Download and apply') on a specific resource ('Poly Haven asset'), so an agent can tell this tool is about acquiring and using assets. It does not explicitly distinguish itself from sibling blender_polyhaven_search, though the verb 'apply' implies more than searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, such as using blender_polyhaven_search first to find an asset ID. It also does not clarify when apply_to is needed, which asset types are supported, or what happens for non-texture assets.
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 disclosure burden. It adds useful context—external service, API-key requirement, two input modes—but omits whether the call is asynchronous, what it returns, and how to track completion. For an AI generation tool with a `_sync` sibling and a `model_status` tool, these are central behavioral facts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action, followed by capability and prerequisite. Each sentence earns its place, though the brevity leaves out important workflow details an agent would need.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no annotations, no output schema, and a sibling set that includes `_sync` and `model_status`, the description should explain the asynchronous workflow and expected return value. It doesn't, so an agent cannot reliably drive the generation call to completion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are already described in the input schema, including enums and defaults, so the description doesn't add meaning beyond the structured data. The text-to-3D/image-to-3D distinction is already captured by the prompt and image_path schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—generate a 3D model via Hyper3D Rodin AI—and names two input modes: text-to-3D and image-to-3D. However, it doesn't differentiate this tool from the sibling `blender_ai_generate_model_sync`, which is likely the synchronous counterpart, so clarity stops short of full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative-routing guidance is provided. The description only mentions the API key prerequisite, but doesn't tell an agent when to choose this async version over `_sync`, or how to check progress via `blender_ai_model_status`. Usage context is left entirely to inference.
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 of behavioral disclosure. It states that a PBR set is generated and applied, but it does not disclose whether execution is asynchronous, whether existing materials are overwritten, how object selection behaves when object_name is omitted, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that packs the core action, output maps, model, and application target without filler. It is appropriately sized and front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no output schema, and a large sibling set including a _sync variant, the description is incomplete. It fails to clarify async behavior, required object_name semantics when auto_apply is true, and how the agent should observe or retrieve generation results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds useful context about the output being a PBR map set, but it does not meaningfully clarify parameter behavior beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: generating a PBR texture set from a text prompt and applying it to a Blender object. It distinguishes itself from texture_from_render and inpaint_texture by emphasizing text-prompt generation and SDXL, though it does not explicitly differentiate from the _sync sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over alternatives such as blender_ai_generate_texture_sync, blender_ai_inpaint_texture, or blender_ai_texture_from_render. The description implies a general use case but does not explain execution mode, prerequisites, 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 carries the full burden of behavioral disclosure. It states the operation and model, but does not explain whether the original texture is overwritten, where output is saved, what side effects occur, or whether a material selection is required first. This leaves important behavioral uncertainty for a generative editing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler or redundant information. It front-loads the action and resource, and the SDXL mention adds meaningful context without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema or annotations, so the description needs to explain expected behavior, return values, and side effects. It only communicates the high-level purpose. An agent is left uncertain about output paths, whether this modifies the texture in place, and how to obtain the resulting image.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already documented clearly (e.g., mask meaning, strength range, prompts). The description does not need to repeat these details. It adds no extra parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and clearly names the resource: inpainted content for a masked region of an existing texture. It also mentions the SDXL model, which adds useful specificity. However, it does not explicitly distinguish itself from sibling texture-generation tools like blender_ai_generate_texture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for editing existing textures with masks, but gives no explicit guidance on when to choose it over related tools such as blender_ai_generate_texture or blender_ai_texture_from_render. There are no when-to-use or 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?
With no annotations provided, the description must carry the burden of behavioral disclosure. It says it builds a complete Geometry Nodes setup, but does not state whether it creates a modifier, overwrites existing node trees, makes instances live, or what side effects occur in the scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with the core promise front-loaded in 'One-call scatter.' The feature list is compact, relevant, and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is thin for a 9-parameter mutating tool with no annotations and no output schema. It omits important context: whether target and instance objects must already exist, what the function returns, whether a modifier is added to the target, and whether existing Geometry Nodes setups are overwritten.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 9 parameters. The description's feature list ('density, Poisson-disk spacing, random scale range...') mirrors the schema descriptions and adds no new semantic detail beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('build'), names the resource ('complete Geometry Nodes setup'), and states the operation ('distributes instances ... across surface of another'). It clearly describes what the tool accomplishes, though it doesn't explicitly distinguish itself from sibling tools like blender_scatter_on_surface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus sibling alternatives such as blender_scatter_on_surface or the lower-level geonode tools. 'One-call scatter' implies a high-level use case, but there are no stated prerequisites, exclusions, or alternative routing.
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 does not disclose whether the deletion is destructive/non-reversible, whether frame defaults to current frame when omitted, how unspecified keyframe channels are handled, or whether an error occurs if no keyframe exists. A mutation tool with no annotation coverage needs more behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence, no filler. It could be slightly more informative, but it is appropriately sized for a focused deletion action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with no annotations and no output schema, the description is thin. It doesn't clarify defaults (current frame), the meaning of index=-1, or what happens if the target keyframe is missing. An agent selecting this tool among 170+ siblings has little context to invoke it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents all parameters. The description itself adds no parameter semantics beyond the schema, and the default-frame behavior of the 'frame' parameter is not explicitly explained in the description. Baseline 3 is appropriate because the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Delete a keyframe from an object property.' It clearly identifies the operation and target. It does not explicitly differentiate from the sibling blender_keyframe_list or blender_keyframe_insert, but the delete semantics are obvious enough given the 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/5Does 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. For example, there is no mention that keyframe_list should be used to inspect existing keyframes before deletion, or that undo exists as a safety net. The description is a bare statement of function with no 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?
With no annotations provided, the description must disclose behavioral traits. It says 'optionally setting its value' but does not explain side effects like whether existing keyframes are overwritten, how frame defaults work, or any requirements for data_path. The mutation implication is clear but under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler, which is excellent for conciseness. However, it is so brief that it sacrifices context, making it less structurally complete than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters including a Blender-specific data_path, but the description only hints at the action and value. It doesn't explain proper property paths, frame handling, or the expected behavior of the index parameter. Without an output schema and with no annotations, an agent would need external knowledge to use this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds only a minor reinforcement of the value parameter, but does not clarify format or interaction between parameters beyond what the schema already states. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert a keyframe') and the resource ('for an object property'), with an optional value-setting capability. It distinguishes from keyframe deletion and listing tools by its verb, but does not explicitly contrast with siblings, so it misses the full definition of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the deletion or listing keyframe tools, nor any mention of prerequisites like object existence or animation context. The agent must infer usage from the tool's name and schema 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, so the description carries the full burden of explaining behavior. It only says 'List all keyframes for an object,' which implies a read-only operation but does not disclose return structure, scope of 'all keyframes,' or any edge behavior. There is no contradiction, but the behavioral context is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with no filler words. It is appropriately concise for a single-parameter listing tool, though its brevity leaves some semantic gaps that other dimensions already penalize.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what the returned keyframe list looks like and what 'all keyframes' includes. It does neither, leaving an agent uncertain about return values, scope, or how keyframes are grouped. This is insufficient for a tool with no structured return information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter ('Name of the object') with 100% coverage, so the baseline is 3. The description adds little beyond restating that keyframes are tied to an object, but it does not provide any extra detail like object naming conventions or how missing objects are handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('list') and resource ('all keyframes for an object'), so an agent can tell this is a read operation on keyframes. It does not explicitly distinguish itself from siblings like blender_action_list or blender_keyframe_insert, but the verb and target are unambiguous enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives such as blender_action_list, blender_keyframe_insert, or blender_keyframe_delete. There is no stated context, prerequisites, or exclusions, so the agent must infer usage from the tool name 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not reveal whether the texture is added as a node in the material graph, whether it replaces existing connections, what happens if the image path is invalid, or what the default target input is when connect_to is omitted. For a mutation tool, this leaves important side effects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single seven-word sentence with zero wasted words. It is concise, but the brevity borders on under-specification since it omits behavioral detail that would strengthen the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema, so the description must compensate, but it is too sparse to do so. It does not explain the resulting material graph state, default connection behavior, prerequisite conditions (e.g., material must exist, image file must be accessible), or failure modes, leaving notable gaps for an agent deciding how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (connect_to, image_path, material_name) with meaningful descriptions. The tool description adds no additional parameter-level detail, so the baseline of 3 is appropriate since the structured schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Add'), a specific resource ('image texture'), and a target ('material'), making the core action clear. However, it does not differentiate itself from closely related siblings like blender_material_node_add or blender_ai_generate_texture, both of which could plausibly be used to bring a texture into a material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as blender_material_node_add, blender_material_set_principled, or blender_ai_generate_texture. No context is provided about scenarios where this tool is preferred, and no exclusions 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It communicates that the tool mutates an object's material assignment, but it does not disclose whether existing material slots are replaced, whether a new slot is created, what happens if the material or object does not exist, or any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler and the action is front-loaded. However, it mostly restates the tool name and offers no additional useful structure, so it is concise but minimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and three parameters, this description is incomplete. It omits prerequisites such as the material and object already existing, does not explain slot behavior, and gives no sense of error cases or return values, leaving an agent to guess important call details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 adds no additional meaning beyond 'material' and 'object'; it does not clarify the optional slot_index behavior or indicate whether material_name must reference an existing material.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core operation clearly: 'assign' a 'material' to an 'object'. It is specific enough to indicate the action, but it does not mention that the material must already exist or explain the role of material slots, so it does not fully distinguish itself from the many related material and object tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context or alternative selection guidance is provided. With sibling tools like blender_material_create, blender_material_set_principled, and blender_material_add_texture, the agent is left to infer when material assignment is the right operation versus material creation or material property editing.
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 the full burden of behavioral disclosure. It does not state whether the new material becomes active, whether a duplicate name is replaced or creates another material, whether shader nodes are required, or what the tool returns upon success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. However, it is so minimal that it misses behavioral context that could be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too thin. An agent cannot tell what side effects occur (e.g., assignment to active object, selection of the newly created material) or what a successful call returns, which matters when coordinating with the many sibling material tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the name and use_nodes parameters. The description adds no parameter-level meaning beyond the schema, which keeps this at the baseline rather than higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
"Create a new material" states a clear verb and resource. It distinguishes itself from sibling material tools like set_color, assign, and list, though it doesn't explicitly name them or explain the exact scope of what 'create' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as blender_material_assign or blender_material_set_principled. There is no mention of prerequisites, whether the material is created as a standalone data-block, or whether it gets assigned to any object.
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 behavioral disclosure burden. It only says 'set', implying mutation, but it does not disclose that the existing base color will be overwritten, whether the material must already exist, what happens if the material is not found, or whether the change affects all objects using that material.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler and the verb-object structure is front-loaded. It earns its place, though it is arguably too terse to carry the behavioral and usage context the tool needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description is not complete. It lacks guidance on error behavior, overwrite semantics, and the distinction from material_set_principled, leaving an agent to guess important operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully documents both material_name and color. The description adds no additional parameter detail beyond implying that the color parameter maps to the base color, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set') and the resource ('base color of a material'), so an agent immediately knows what the tool does. It is specific enough to be distinguished from siblings like material_create or material_assign, but it does not explicitly differentiate itself from blender_material_set_principled, which may also affect base color among other settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives. It does not mention that this is for simple base-color changes only, nor does it point to material_set_principled for full material setups, leaving the agent to infer the correct scope.
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. The verb 'Remove' implies a destructive action, but the description does not state that the modifier is permanently deleted, what happens if the object or modifier does not exist, or whether the operation is undoable. For a mutating operation, this is a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single seven-word sentence that is front-loaded with the operative verb. Every word earns its place and there is zero filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description must set expectations for the agent on its own. It fails to mention success/failure behavior, error conditions, permanence of the removal, or any side effects — information an agent needs to safely invoke a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (object_name, modifier_name). The description adds no additional meaning beyond the schema, but per the baseline for high schema coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Remove') and resource ('a modifier from an object'), making the tool's function unambiguous. It is clear and distinct from siblings like blender_modifier_add, blender_modifier_apply, and blender_modifier_configure by virtue of the verb choice, though it does not explicitly call out sibling distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention relevant workflows such as checking available modifiers via blender_modifier_list first, or choosing between permanent removal versus blender_modifier_apply for baking the effect.
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 the single-file versus separate-files behavior, but leaves 'proper structure' vague and does not disclose whether files are overwritten, whether existing LOD hierarchies are required, or how the export affects the Blender scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the primary action and key output modes. The phrase 'proper structure' is somewhat vague, but overall the description is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a file-export tool with no annotations and no output schema, and the description is too minimal for the complexity of MSFS LOD workflows. It does not mention prerequisites, file formats, relationship to the LOD setup pipeline, error conditions, or how the result will be named or organized beyond the separate-files toggle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description only loosely restates the separate_files behavior ('single file or separate files per LOD') and adds no extra meaning about base_name or output_dir, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Export') and resource ('LOD hierarchy'), and adds a meaningful distinction with 'single file or separate files per LOD.' It is clear on what the tool does, though it does not explicitly differentiate from the sibling blender_msfs_export_model, so a top score is not warranted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus related tools like blender_msfs_create_lod_hierarchy, blender_msfs_setup_lod_distances, or blender_msfs_export_model. The description implies the purpose but provides no context, prerequisites, 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?
No annotations are present, so the description must disclose behavior itself. It only says 'Configure...' without stating that this modifies the active scene/object, what objects it applies to, whether it requires an existing animation action, what gets changed, or what the side effects are.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and has no fluff, but it is also extremely sparse for a tool with five parameters. It is concise in word count rather than informative, providing only a single high-level phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a fairly simple configuration tool, the description is adequate when combined with the fully described input schema. However, it does not explain prerequisites or the broader workflow context, and with no annotations the description is too thin to give the agent full confidence in its side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a clear description with defaults. The tool description does not add any meaning beyond what the schema provides, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Configure animation looping behavior for flight simulator.' It is clear enough to distinguish from playback or keyframe tools, though it does not mention the specific behaviors (once, loop, ping_pong, hold) or how it relates to other MSFS animation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like blender_msfs_add_animation_tag, blender_msfs_setup_visibility_animation, or generic animation tools. No prerequisites, exclusions, or context 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 provided, the description carries the full burden of behavioral disclosure, and it only says the tool creates a simplified mesh. It does not reveal whether the source object is preserved or modified, whether a new object is generated, whether the operation is destructive or reversible, or how the collision_type parameter affects the outcome. An agent cannot predict the side effects of invoking it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler, front-loading the verb and resource. It earns its place, though a second sentence clarifying side effects or sibling choice would strengthen the definition without adding bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, four parameters, and several closely related siblings, yet the description offers only its one-line core function. Missing are the collision workflow context (box vs. convex vs. simplified), the effect on the source object, and any explanation of the enum semantics, leaving an agent under-equipped to invoke it correctly within the larger MSFS export pipeline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3: every parameter already has a description, including defaults for simplify and simplify_ratio. The tool description itself adds no meaning beyond the schema, and the collision_type enum values (none/collider/road/water/trigger) remain semantically opaque even though they materially change the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a simplified collision mesh from a source object for physics interactions.' The qualifier 'simplified' plus the word 'mesh' implicitly differentiates it from the sibling tools blender_msfs_create_collision_box and blender_msfs_create_collision_convex, but it never names those alternatives, so the differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool over its direct siblings (collision_box, collision_convex) or the related blender_msfs_tag_collision_type and blender_msfs_decimate_for_lod tools. There are no stated prerequisites, no when-not-to-use conditions, and no indication of where this step fits in the MSFS collision-authoring workflow.
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 of behavioral disclosure. It mentions the texconv dependency, which is useful, but it does not disclose whether the tool overwrites files, what DDS format/compression is chosen for each texture_type, whether it creates directories, or what errors occur with missing texconv. For a file conversion tool with side effects, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the core action and a critical prerequisite in parentheses. It is front-loaded with the main purpose, and every word earns its place. It could be slightly more structured, but for its length it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, no annotations, and the tool is one of many MSFS livery and export tools. The description lacks prerequisite context (texconv installation path), behavioral detail (file overwrite, compression mapping), and any guidance on how this relates to the livery export pipeline. For a tool with three parameters and side effects, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the three parameters. The description adds the context that texture_type values map to format selection, which is marginally helpful, but it repeats the parameter names without adding format syntax, file extension behavior, or default path logic. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Convert') and resource ('texture to DDS format for MSFS'), which clearly distinguishes it as a format conversion tool within the MSFS livery toolset. It doesn't name sibling alternatives, but the MSFS-prefixed siblings are mostly about livery setup, materials, and exports, so the conversion purpose is reasonably distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like blender_msfs_livery_export_textures or blender_material_add_texture. The parenthetical '(requires texconv)' implies an external dependency but does not explain when conversion is necessary or what inputs are appropriate. Usage context is left entirely to inference.
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 the core action and resolution intent, but does not disclose whether files are downloaded from an external source or generated locally, whether existing files in output_dir are overwritten, what side effects occur, or what happens on failure. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words and the key action is front-loaded. It is concise and easy to scan, though the brevity contributes to the lack of contextual detail elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool embedded in a large livery-related sibling group, the description is too thin. It does not explain the expected workflow, what template files are produced, how the resolution is determined, or how the output relates to other livery tools. Without an output schema or annotations, an agent lacks enough context to invoke this reliably in the correct sequence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already documented descriptively ('Directory to save template files' and 'Aircraft identifier'). The description adds little beyond that, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Download or generate') and resource ('template files for an aircraft'), and the qualifier 'at correct resolution' adds useful scope. It does not explicitly distinguish itself from related livery template siblings like get_aircraft_templates or load_template_overlay, so it falls just short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as blender_msfs_livery_get_aircraft_templates or blender_msfs_livery_load_template_overlay. The description provides no context about prerequisites, workflow position, or situations where a different tool would be more appropriate.
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 disclose behavior on its own. It states that a UV map and paint texture are created, but does not say whether existing UV maps/textures/material assignments are overwritten, whether the object must already exist, or whether the operation is destructive/reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, and the main action is front-loaded. It is slightly terse but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description leaves important context uncovered: prerequisites, side effects on material/UV state, how it relates to other livery painting tools, and what success looks like. It is adequate only as a minimal summary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented in the input schema. The description adds no detail beyond the schema, such as how texture_resolution relates to the paint texture, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action ('Set up an object for texture painting') and the artifacts involved ('UV map and paint texture'), so an agent understands the tool's role. It does not explicitly contrast it with nearby livery tools like blender_msfs_livery_set_paint_brush or create_paint_layers, so it falls just short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to call this tool, what prerequisites apply, or which sibling tool should be used instead (e.g., for brush setup or paint-layer creation). The intended usage is only weakly implied by the verb 'Set up'.
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 of behavioral disclosure. 'Configure' implies a mutating operation, but the description does not state side effects (e.g., overwriting existing distances), whether it applies to all objects with the base_name, or if it returns any confirmation. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the purpose. It is appropriately sized for its limited scope, though it sacrifices necessary context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that configures LOD distances and has a nested object parameter, the description is too minimal. It doesn't explain return values (no output schema), prerequisites, or interaction with other LOD tools. An agent would likely need to inspect the schema and sibling tools to understand the expected workflow, making this incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage: base_name is described as 'Base name of the LOD hierarchy' and distances includes an example format. The description itself adds no extra semantics beyond the schema, so it 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Configure LOD switching distances for flight simulator' clearly identifies a specific verb (configure) and resource (LOD switching distances) within a flight simulator context. It distinguishes from siblings like create_lod_hierarchy and decimate_for_lod by focusing on distance configuration. However, it lacks a direct mention of the base_name parameter or that it applies to an existing hierarchy, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as blender_msfs_create_lod_hierarchy or blender_msfs_get_lod_info. It doesn't mention prerequisites (e.g., hierarchy must exist), nor does it describe the intended workflow position. An agent is left to infer usage from the tool name 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?
There are no annotations, so the description carries the full burden. It discloses the basic show/hide behavior but does not mention side effects such as whether keyframes are created, whether existing visibility animations are overwritten, whether an MSFS animation tag is added, or how hidden_range and visible_range interact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear, front-loaded sentence with no filler. It is efficient and easy to parse, though it is sparse on details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating setup tool with no annotations and no output schema, the description is too thin. It omits preconditions, what happens in the scene after the call, and how the two frame-range parameters should be supplied together. An agent would have to infer important operational details from the schema and tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds no additional parameter-level meaning beyond the schema, such as whether ranges are optional, mutually exclusive, or have defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set up') and resource ('visibility animation') plus the object scope, and clarifies behavior as show/hide during frame ranges. It is reasonably distinct from generic animation tools, though it does not explicitly differentiate from sibling MSFS animation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like blender_msfs_add_animation_tag or blender_keyframe_insert. It only implies the MSFS context through the tool name and sibling family.
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, but it only says 'validate... and report issues.' It does not state whether the operation is read-only or mutates the model, which specific compatibility checks are performed, or how issues are returned. The term 'report issues' hints at output but leaves the agent guessing about side effects and result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single nine-word sentence with no filler; the action verb is front-loaded and every word carries meaning. 'Validate' states the action, 'for flight simulator compatibility' gives the domain, and 'report issues' discloses the output. This is appropriately sized for a tool with one optional parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's surface simplicity, MSFS validation is domain-specific and the description does not say what compatibility criteria are checked, what issue types are reported, or whether the call is safe/non-destructive. There is no output schema or annotation to fill these gaps, and no relationship to the export workflow is stated. An agent cannot reliably predict what happens when it invokes this tool or how to act on the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single optional parameter object_name is already well documented ('Specific object to validate (omit for all selected/all)'), so the baseline is 3. The description's plural 'model(s)' loosely aligns with the parameter's scene-level default but adds no format, naming, or usage detail beyond the schema. Nothing in the description compensates for or contradicts the schema, so a baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Validate'), a resource ('model(s)'), and a distinguishing domain ('flight simulator compatibility'), and states the output behavior ('report issues'). This separates it from generic validation siblings like blender_validate_dimensions and blender_validate_mesh_quality. It loses a point because 'model(s)' is slightly ambiguous and it doesn't explicitly name what it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as blender_validate_mesh_quality, blender_validate_dimensions, or blender_msfs_livery_validate_package. There is no mention of prerequisites (e.g., run before export, select objects first) or exclusions. Usage context is only weakly implied by the MSFS prefix in the tool name.
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 disclosure burden, yet it only restates the operation type. It does not disclose what properties are actually returned, how a missing object name is handled, or whether the tool has any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Six words, front-loaded with the verb and object — no wasted text. It errs on the side of under-specification rather than verbosity, but as pure conciseness it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain what 'detailed properties' means for an agent to know whether this answers its question. Set against a sibling list of over 200 tools with several overlapping object-introspection options, this one-liner leaves the agent guessing about return contents and error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the sole parameter 'name' is documented as 'Name of the object.' The description's 'an object' maps cleanly onto that parameter but adds no extra meaning (name format, case sensitivity, scene context requirements), so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific read verb ('Get'), a resource ('detailed properties'), and a clear scope ('of an object'). The 'detailed' qualifier loosely distinguishes it from blender_object_list, but it doesn't define what 'detailed properties' covers or differentiate it from blender_object_transform or blender_scene_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to prefer this over blender_object_list, blender_object_transform, or blender_scene_info, all of which overlap in reading scene/object state. The only implied context is that a single named object is required; no alternatives or exclusions 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the intended result but does not describe that source objects are removed into the active object, which object persists, ordering semantics, prerequisites, or reversibility. For a mutating operation this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with no filler or redundant information. It is front-loaded and efficient, precisely stating the operation in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, this description is too sparse. It omits the active-object behavior, what happens to the source objects, naming/transform inheritance, and any constraints on the input list, all of which are relevant for an agent to invoke the tool correctly and predict the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the 'names' parameter with 100% coverage, so the description adds only the implication that multiple objects are expected. It does not clarify whether the first name is the active/result object or whether any minimum count or selection state is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('join'), a resource ('objects'), and the outcome ('into one'), so the core purpose is clear. However, it does not contrast this with the closely related peer blender_mesh_merge, leaving some potential ambiguity at the object vs. mesh level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as blender_object_separate, blender_mesh_merge, or boolean operations. There are no explicit when-to-use or when-not-to-use conditions, so the agent must infer all selection logic.
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 states the high-level outcome but not important side effects such as implicit transform inheritance, replacement of an existing parent, or the clearing behavior when parent is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise, front-loaded sentence with no wasted words. It is appropriately brief for a simple operation, though an extra clause about clearing the parent would have made it even more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is thin. It omits the clear-parent behavior, expected side effects on hierarchy/transforms, and any indication of what the tool returns or errors on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies; the schema already defines child and parent and notes that omitting parent clears it. The description adds no parameter details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific operation and resource: 'Set parent-child relationship between objects.' This clearly distinguishes the action of parenting from nearby object tools like join, but it does not explicitly contrast with any sibling or mention the clear-parent case served by omitting parent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use parenting versus alternatives such as join, constraints, or collection hierarchy tools. The description implies the intent (establish hierarchy) but provides no exclusions or selection 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 carries the full burden of behavioral disclosure. It does not state whether selection is additive or replacing by default, what happens when no object matches the name or pattern, whether names and pattern can be combined, or whether selection applies to the active scene. The existence of deselect_others hints that selection may be additive, but the description never states it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six words, front-loaded with verb and resource, with no wasted content. It is maximally concise, though the brevity comes at the cost of behavioral context that other dimensions have to penalize.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity (3 optional params, no nesting, no output schema), but critical semantics remain undocumented in both the description and the schema: whether names and pattern are mutually exclusive or combinable, the default behavior of deselect_others, and failure handling when nothing matches. With no annotations or output schema to fill these gaps, the definition is incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters clearly described and the pattern parameter including a concrete glob example. The description adds only marginal value beyond the schema by tying the two selection modes ('by name or pattern') together, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Select'), a specific resource ('objects'), and the selection mechanism ('by name or pattern'). The object-level resource implicitly distinguishes it from the blender_mesh_select* family, but it never explicitly names or contrasts any sibling, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as blender_object_get, blender_object_list, or the mesh-selection tools. The tool's role as a precursor to downstream object operations is left entirely to inference from the naming convention.
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 of explaining side effects, but it only states the operation and the modes. It does not disclose whether the original object is replaced by new pieces, whether SELECTED requires edit-mode selection, or whether the operation is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the action and enumerates the key modes without filler. It is as concise as possible for the information it provides.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema or annotations and performs a potentially irreversible mesh/object restructuring, yet the description does not explain default behavior when mode is omitted, what happens to the original object, or what input context is required. This leaves an agent without enough information to use the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both name and mode and fully documents the mode enum, so the description adds little parameter-level meaning. It essentially restates the enum values in prose, which provides baseline coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Separate' with the object as the target and enumerates the three modes (loose parts, materials, selection), so an agent knows what action this tool performs. It does not distinguish this tool from the closely named sibling blender_mesh_separate_selected, so sibling differentiation is incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over alternatives like blender_mesh_separate_selected, nor about prerequisites such as needing an active selection for SELECTED mode or whether the object must be a mesh. The intended usage must be inferred from the name and enum values.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It indicates a non-mutating external search and the free asset types, but it does not disclose that the tool likely only returns results and does not download or import assets, nor does it mention network requirements or response behavior. This is a significant transparency gap for an unannotated 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource while including the searchable asset categories. There is no filler, repetition of schema details for its own sake, or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema and a closely related download sibling, the description should clarify that the tool returns search results and that a separate download action is needed to obtain assets. This workflow is left implicit, and the absence of annotations increases the need for that context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters sufficiently. The description restates the asset_type values in prose ('HDRIs, textures, or 3D models') but adds no additional semantic meaning for 'query' or 'categories' beyond what the input schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Search') and a specific resource ('Poly Haven'), and enumerates the asset categories searched: HDRIs, textures, or 3D models. This makes the core purpose clear and broadly distinguishes it from the download sibling, though it does not explicitly contrast it with any alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not say when to prefer this tool over blender_polyhaven_download, nor does it mention that search results still require a separate download step. The intended workflow is only implied by the verb 'Search'.
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 of behavioral disclosure. It only confirms a read operation and names the data categories returned ('details and iteration history'), without revealing response shape, iteration-history ordering, error behavior for an invalid session_id, or whether an active session is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler — the verb and resource appear immediately. It is efficient, though slightly more contextual detail could have been added without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the agent's only source for what 'details' and 'iteration history' actually contain. The text is too thin: the agent cannot predict the response structure, the outcome of a bad session_id, or how to obtain a valid session_id (e.g., from create_session or list_sessions).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with session_id already documented as 'Refinement session ID,' so the schema carries the parameter meaning. The description adds nothing about where to obtain a session_id or what format it takes, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('a refinement session'), and a defined scope ('details and iteration history'). It is clearly different from siblings like blender_refine_create_session, blender_refine_list_sessions, and blender_refine_iteration, though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus blender_refine_list_sessions, blender_refine_iteration, or blender_ai_refine. There are no exclusions, prerequisites, or mentions of alternatives; the agent must infer usage purely from the tool name.
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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states that output goes to files; it does not disclose whether rendering blocks, how start/end frames behave when omitted, whether existing files are overwritten, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is concise and well-structured, though the brevity limits how much behavioral context it can provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Rendering an animation is a non-trivial operation with no annotations and no output schema. The description omits important context such as default frame range behavior, placeholder requirements, file format defaults, and whether the operation blocks until completion. The schema documents parameter names but not the full execution context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all four parameters with 100% coverage, so the baseline is 3. The description adds no extra parameter meaning, but it does not need to because each parameter already has a schema description, including 'Output path (with frame placeholder)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Render the animation to files' clearly identifies the verb (render), resource (animation), and output target (files). It distinguishes this from sibling tools like blender_render_image and blender_render_screenshot, though it does not explicitly contrast with blender_render_multi_angle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like blender_render_image or blender_render_screenshot, and no prerequisites are mentioned. Usage is only implied by the word 'animation' in the tool name and description.
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?
The description only states the action without covering side effects, return values, or potential overwrite behavior. It does not disclose whether the current scene is replaced or if a new unnamed scene is created when 'name' is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core action without redundant details. It is efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not mention returns, errors, or edge cases. It lacks critical contextual information that an agent would need to use it correctly in a workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'name' has a clear description in the schema, but the description adds no extra nuance about naming conventions, default values, or constraints. Since it's optional, behavior when omitted is unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and the resource (a new scene), distinguishing it from sibling tools like scene info or clear. The verb-resource pair is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 such as scene info or clear. The description offers no context about typical use cases or prerequisites.
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 of behavioral disclosure. It fails to mention whether setting the range clips or preserves existing keyframes, whether it affects playback or render range, or what the scene state should be. For a mutation tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; every word contributes to stating the action. It is appropriately sized for a simple two-parameter tool, though it is terse enough that slightly more context could be added without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with two fully documented parameters and no output schema, so the basic action is adequately described. However, given both parameters are optional and no annotations exist, an agent is left guessing about defaults and behavioral implications, leaving clear but not severe gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with 'Start frame' and 'End frame' already documented in the input schema. The description adds no parameter-level detail beyond the schema, which is acceptable at the baseline of 3 for full coverage, though it doesn't clarify bounds semantics like inclusivity or ordering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and specific resource ('animation frame range'), making the core action unambiguous. It doesn't explicitly differentiate from siblings like blender_animation_goto_frame or blender_keyframe_insert, but the name and phrasing make the range-setting intent fairly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as blender_animation_goto_frame for single-frame navigation or blender_keyframe_insert for adding keys. It also doesn't explain what happens when only one of the two optional parameters is supplied, which is a significant usability gap.
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 must carry the full behavioral disclosure burden. It mentions the resume action but does not clarify whether resume mutates the pipeline, whether status is read-only, what side effects resume has, or how 'last successful stage' is determined. This is notably thin for a tool that appears to support both a read operation and a continuation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler and the primary action is front-loaded. It is compact and easy to parse, which is appropriate for a tool with only two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and the schema covers all parameters, but there is no output schema and no annotations, so the description should explain what status information is returned and what resuming actually does. The description is adequate for a high-level understanding but leaves an agent uncertain about return shape and the semantics of the resume operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both pipeline_id and resume. The description adds little beyond what the schema provides, though the phrase 'resume from last successful stage' helps clarify the intent of the resume boolean. It does not explain parameter format, defaults, or behavior when resume is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action—get status of a pipeline run—and adds a second behavior, resume from last successful stage. It is specific to pipeline runs and references the pipeline_generate counterpart indirectly through the schema. However, bundling 'status' and 'resume' into one tool muddies the purpose slightly and it does not explicitly differentiate itself from sibling status tools like blender_ai_model_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used after blender_ai_pipeline_generate to inspect or continue a pipeline run, but it gives no explicit when-to-use guidance. There is no explanation of when to call status versus when to resume, and no mention of alternatives or exclusions. Among a very large sibling list, an agent gets little routing help beyond the tool name.
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 behavioral disclosure burden, but it only restates the basic toggle action. It does not disclose what happens when the optional 'play' parameter is omitted, whether playback blocks execution, whether it affects only the viewport/timeline, or whether calling play=true while already playing is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single six-word sentence with zero waste and the verb front-loaded. For a one-parameter boolean toggle, this length is appropriately sized, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity (one optional boolean, no output schema, no nested objects), so the description is mostly adequate. However, because there are no annotations and no output schema, the description is the only source of behavioral context, and it leaves the omitted-parameter behavior and the playback scope (viewport vs. timeline) unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter description ('True to play, false to pause') is self-explanatory, so the baseline of 3 applies. The tool description essentially echoes the parameter semantics without adding extra meaning, and the optionality with no declared default remains slightly ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb pair ('Play or pause') with a clear resource ('animation playback'), making the action unmistakable. It is implicitly distinguished from siblings like blender_animation_goto_frame (seeking) and blender_render_animation (rendering to output), though it doesn't explicitly name those 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as blender_animation_goto_frame or blender_render_animation. There is no mention of whether this is for viewport preview, how it relates to scrubbing frames, or any prerequisite scene state, so an agent must infer all usage 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?
With no annotations present, the description carries the full burden of behavioral disclosure. It merely states that a collection is created and that collections organize objects. It does not mention potential behaviors such as what happens if the name already exists, whether the collection is created under the Scene Collection by default, or what the tool returns/does not return. This is a minimal behavioral description for a creation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no redundant wording. The first sentence front-loads the core action, and the second adds relevant conceptual context about collections. Every word earns its place; there is no filler or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create operation, the description is mostly adequate, and the schema covers all parameters. However, with no output schema and no behavioral notes about default parent behavior or name conflicts, an agent still has to infer some execution details. It is not incomplete enough to be dangerous, but it could be richer given that the description is the only source of behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters (name, parent, color_tag) with descriptions and enum values, giving 100% schema description coverage. The tool description does not add parameter-level detail beyond the schema. Because the schema already carries the meaning, a 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Create a new collection,' which is specific and unambiguous. It conveys the essential purpose of collections in the Blender scene hierarchy. However, it does not explicitly differentiate this tool from sibling tools like blender_collection_list, blender_collection_move, or blender_collection_instance, relying mostly on the verb 'create' to distinguish it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 explains what collections do conceptually but does not say 'use this when you need a new collection,' nor does it mention any conditions or exclusions. There is no reference to siblings such as blender_collection_list or blender_collection_move that would help an agent choose correctly.
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 states the basic move action and optional removal, but does not disclose whether the target collection must already exist, how multiple current memberships are handled, or any side effects beyond collection membership.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the core action and the key optional behavior with no filler. The main verb and resource appear first, making the description easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation tool, the schema plus description are enough to make a basic call. However, with no annotations or output schema, it would benefit from clarifying target-collection existence requirements and the distinction from instancing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds little beyond restating that objects are moved and may be removed from current collections, which the schema already covers in more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Move' with a clear resource ('objects') and destination ('target collection'), and notes optional removal from current collections. It is clear on its own, though it does not explicitly differentiate itself from the sibling blender_collection_instance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as blender_collection_instance, nor any prerequisites or exclusions. The optional removal behavior hints at a use case, but the tool does not state when moving is preferred to instancing/linking.
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 carries the full burden of behavioral disclosure. It only says 'Export to USD' and does not mention that this writes a file, may overwrite an existing file, or any other side effects such as export scope or failure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word earns its place, and the key action and format are immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple export tool with fully documented parameters, the description is minimally viable. However, with no annotations and no mention of file-overwrite behavior or alternatives among export siblings, there is room for additional context that would help an agent invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 with its meaning. The description adds nothing beyond the schema, which is acceptable but does not elevate the score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Export) and the target format (USD/Universal Scene Description), making the tool's core function obvious. It is distinguishable from export siblings like blender_export_gltf or blender_export_fbx, though it does not explicitly call them out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose USD over the other export formats (glTF, FBX, OBJ, STL) or which pipeline scenarios require USD. The agent must infer usage solely from the tool name and format.
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, but it only states the core operation. It does not disclose whether the source object loses the separated faces, whether the original remains intact, where the new object is placed, or how default naming works. The description also says "selected faces" while the schema requires explicit face_indices, leaving ambiguity about whether it uses current selection or supplied indices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the main action immediately. The examples after the em dash add context without being bloated, though they are somewhat redundant with the core statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating mesh operation with no annotations and no output schema, the description is thin. It omits side effects on the source object, the default behavior when new_name is omitted, whether the operation is reversible, and what the tool returns. An agent would need to infer important operational details from the tool name and parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter names and descriptions already explain object_name, face_indices, and new_name. The description adds no parameter-level detail beyond the schema, which is acceptable but not additive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: "Separate selected faces into a new object." The em-dash extension clarifies the intent as extracting parts into independent objects. However, it does not explicitly distinguish itself from siblings like blender_object_separate or blender_mesh_split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through examples like "extract body panels, components, or regions into independent objects," giving some context for when the tool is appropriate. It does not state when to prefer this over blender_object_separate, blender_mesh_split, or blender_object_duplicate, nor does it mention any 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?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It states the core subdivision action and selective scope, but does not mention that the operation mutates mesh geometry, whether it must run in edit mode, whether results are destructive or undoable, or what happens when edge_indices is omitted. The wording 'selected edges/faces' also does not align cleanly with the schema's edge_indices-only parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the primary action. The second sentence adds a useful scope qualifier. There is mild redundancy between 'add resolution' and 'add geometry,' but overall every sentence earns its place and the description is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description should provide more operational context. It does not explain selection requirements, the result of omitting edge_indices, failure states, or how the 'faces' part of the description maps to the available parameters. The schema provides parameter detail, but the description is too thin to fully guide correct invocation for a mutating mesh tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented and the baseline is 3. The tool description adds no parameter-specific semantics beyond noting selective subdivision, and its mention of 'faces' is not reflected in the schema, which only exposes edge_indices. Still, the schema fully covers the five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Subdivide selected edges/faces to add resolution.' It also clarifies scope with 'without subdividing the entire mesh,' which helps distinguish it from whole-mesh subdivision operations. It does not explicitly name or contrast sibling tools like loop_cut or bevel, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Add geometry where needed without subdividing the entire mesh' implies selective/local use cases but does not explicitly state when to prefer this tool over siblings like blender_mesh_loop_cut, blender_mesh_bevel, or blender_mesh_dissolve. There is no when-not-to-use guidance or named alternatives, leaving usage largely to inference.
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 available, the description carries the full burden of disclosing effects. It only says 'Add', implying mutation, but does not explain what is modified, whether existing tags are overwritten, whether the object must already exist, or what happens on success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repeated information. It communicates the essential purpose efficiently and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents the required and optional parameters, making the tool invocable from the structured data alone. However, the description lacks any explanation of how animation tags fit into the broader MSFS animation workflow, how they relate to list_animation_tags or configure_animation_loop, or what a successful call returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter descriptions already document object_name, tag_type, frame, and tag_data. The tool description itself adds no additional parameter semantics beyond referring to the general concept of an animation tag/event marker.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Add'), the resource ('animation tag/event marker'), and the domain ('flight simulator animation events'). It is specific enough to know what the tool does, though it does not explicitly distinguish itself from related MSFS animation tools like setup_visibility_animation or configure_animation_loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, and it does not state prerequisites such as requiring an existing animated object. The only context provided is the broad phrase 'for flight simulator animation events', which is more a domain label than actionable usage 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 the full burden of behavioral disclosure. It fails to state what the analysis returns, whether it modifies anything, whether it writes files, or what 'region analysis' means, and no feedback/result format is described. For a read-only analysis tool, this is a substantial gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that names the action and the objects of analysis, front-loaded with the core purpose. It earns its place with 'colors, patterns, and design elements' and the aircraft_type hint, but could include a brief result statement without bloating.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and two potentially ambiguous parameters, the description is thin. An agent cannot tell what the tool will return, whether it is safe/destructive, or how the optional aircraft_type changes behavior. The sibling list shows many livery tools, so more routing context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 the phrase 'for region analysis' to the aircraft_type parameter, which is a small semantic contribution beyond the schema. It doesn't explain image_path format, supported file types, or how aircraft_type affects analysis, but the schema already covers the basic meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Analyze') and resource ('livery image'), specifying the three output aspects: colors, patterns, and design elements. It distinguishes itself from sibling livery tools like sample_color and extract_colors, though it doesn't explicitly mention those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for analyzing livery images and mentions an optional aircraft_type for 'region analysis', giving some context. However, it provides no explicit when-to-use guidance or exclusions, and the sibling set contains several overlapping livery-analysis tools (sample_color, extract_colors, map_elements) with no differentiation.
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 of behavioral disclosure. It mentions export formats and an output destination in the schema, but does not disclose whether files are overwritten, whether the object must already have livery materials, what texture maps are exported, or what the tool returns. Minimal behavioral context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. The core action and supported formats are front-loaded, making it easy to scan. It is concise without being uselessly terse, though a bit more workflow context would improve it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-exporting tool with no annotations and no output schema, the description should clarify prerequisites, output artifacts, and the relationship to DDS conversion. It only states the action and formats, leaving the agent to infer when in the MSFS livery pipeline this should be used and what success looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters meaningfully. The description itself adds little parameter-level detail beyond 'from an object' aligning with object_name, and format names appearing in the format parameter. A baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (export) and the resource (livery textures from an object), and names the supported output formats: PNG, TARGA, or for DDS conversion. It is distinguishable from sibling tools like blender_msfs_livery_export_uv_layout and blender_msfs_livery_convert_to_dds, though the distinction is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'or for DDS conversion' implies a workflow where this tool is used before blender_msfs_livery_convert_to_dds, but it never explicitly states when to use this tool versus alternatives or when not to use it. There are no direct exclusions or sibling comparisons, so guidance remains inferred rather than stated.
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 carries the full burden of behavioral disclosure. 'Map' is ambiguous: it does not state whether this modifies the target, requires existing templates, or is a read-only lookup. The observable effects and return behavior are not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It delivers the core action and resource efficiently, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and an ambiguous core verb, the description is not self-sufficient. It lacks information about prerequisites, what 'mapping' changes, possible return values, and how this fits into the livery workflow among many related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context by naming the valid design element types (cheatline, logo, registration), which clarifies the 'elements' parameter beyond its generic schema text. It also reinforces the relationship between source_aircraft and target_aircraft.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Map design elements ... between aircraft templates,' and it lists concrete element types (cheatline, logo, registration). It clearly communicates the general operation, though it does not explicitly differentiate itself from sibling livery tools like blender_msfs_livery_transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus related tools such as blender_msfs_livery_transfer or blender_msfs_livery_load_template_overlay. There are no stated prerequisites, exclusions, or workflow context, so an agent must infer the appropriate usage.
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, but it only says 'Configure paint brush settings' and does not explain side effects, persistence, whether it requires active paint mode, or whether it resets other brush properties. The listed presets provide some useful detail, but mutation semantics and any operational constraints are unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the core action and then adds the most useful non-schema information. There is no filler, repetition, or clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a workflow-specific MSFS livery context, the description is too thin. It does not explain how brush settings interact with the livery painting workflow, whether paint mode must already be active, or what the expected result is. An agent would need to infer too much from the name and sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all four parameters with 100% coverage, so the baseline is 3. The description adds value by enumerating concrete preset values (soft_airbrush, hard_edge, detail_brush, smudge, clone, fill) that the schema's generic 'Brush preset name' does not provide, which materially helps an agent pick valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Configure') and a clear resource ('paint brush settings'), and lists concrete preset names, which helps an agent understand the tool's intent. It is distinguishable from siblings like sample_color or get_paint_presets by focusing on configuration rather than querying or sampling. It stops short of explicitly contrasting with those siblings, so it does not earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus sibling tools such as blender_msfs_livery_setup_paint_mode or blender_msfs_livery_get_paint_presets. There is no mention of prerequisites like entering paint mode first, nor any indication that get_paint_presets should be used to discover valid presets. Context must be inferred entirely from the tool name.
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 behavioral burden. It only says 'set up' without disclosing whether the material is created or modified, whether existing properties are overwritten, what 'extensions' are added, or any side effects. This is insufficient for a mutation-oriented tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and readable, though slightly generic in the verb 'set up.' Still, it earns its place and is appropriately compact for the amount of information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, an enum, no annotations, and no output schema, the description is too thin. It does not explain whether the material must already exist, whether optional parameters update only the provided values, or what the resulting MSFS extension setup entails. An agent would need to inspect schemas or guess about the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 9 parameters with 100% coverage, so the baseline of 3 applies. The description adds no additional parameter-level meaning, such as relationships between msfs_type and the PBR values, but it does not need to since the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (set up) and the resource (a material) with a specific domain (flight simulator PBR properties and extensions). It is not a tautology and is distinguishable from generic material tools, though it does not explicitly contrast with specialized siblings like blender_msfs_create_glass_material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'flight simulator-specific' implies the tool is for configuring MSFS PBR materials, giving some usage context. However, it provides no explicit guidance on when to use this tool versus related material tools, no prerequisites, and no mention of 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?
With no annotations, the description alone must convey behavioral implications. It only states the deletion action but does not mention side effects like irreversibility, impact on related objects (e.g., children), or error handling if the name doesn't exist. This lack of detail leaves the agent unaware of potential consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action. It contains no redundant words and is appropriately sized for its function. Structure is direct and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema, the description might seem sufficient, but it omits key context: what happens on success or failure, whether a confirmation is needed, or any side effects on the scene. For a destructive operation, this lack of completeness could lead to misuse. The absence of an output schema further compounds the ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already defines the parameter 'name' with a description 'Name of the object to delete'. The tool description merely repeats 'by name' without adding extra context, such as expected format, case sensitivity, or uniqueness. It does not enhance the schema's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete an object by name'. It specifies the verb 'delete' and the resource 'object', distinguishing it from other object operations like create, list, or transform. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. For example, it doesn't mention conditions like object existence, or whether it should be used before cleanup operations. The user must infer usage from the sibling tools.
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 behavioral disclosure burden. It confirms that a session is created and that it tracks iterative improvement, but it does not explain what a session is, whether it creates Blender-side state, what it returns, or how it relates to subsequent iteration calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. It is concise, though the conciseness leaves out important behavioral and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a stateful session-creation tool with no annotations and no output schema, yet the description only provides a one-line purpose. It does not explain the session lifecycle, prerequisites, how prompt/reference_image are used, or what the agent should do after creating the session, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds no additional meaning about how 'prompt', 'object_name', or 'reference_image' are used in the session, but it is not required to compensate for a coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 refinement session') plus a clear goal ('track iterative improvement of a 3D model'). It is distinguishable from the sibling tools like blender_refine_iteration and blender_refine_list_sessions, though it does not explicitly contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to track iterative improvement' implies that this tool is for starting a session in an iterative refinement workflow, but it does not explicitly say when to use it versus alternatives like blender_ai_refine, or state that iteration calls should follow session creation. The usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It states the output is a file, but says nothing about whether an existing file is overwritten, which engine/resolution is used, progress/return behavior, or other side effects. This leaves the agent with only the literal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and target ('Render the current frame to a file') has no filler and communicates the core task immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal schema and simple task, the description is adequate for a straightforward call, but it lacks guidance on overwriting behavior and doesn't clarify the boundary against render/screenshot siblings. It is minimally complete rather than fully contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both output_path and file_format have concise descriptions plus an enum for file_format. The description adds no parameter-level detail, but per the rubric the baseline is 3 when the schema already documents the parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Render the current frame to a file.' It is unambiguous about what the tool does and the singular 'current frame' hints at the contrast with render_animation. However, it does not explicitly call out sibling differentiation, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this over blender_render_animation, blender_render_screenshot, or blender_render_multi_angle, and no prerequisites are mentioned. An agent must infer from the sibling names when this single-frame render is the right choice.
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 of behavioral disclosure. It only restates that the engine is set, without explaining side effects, prerequisites like an active scene, or persistence of the setting across renders. For a mutating tool, this is 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core action. Every word earns its place, and nothing extraneous is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter setter, the schema plus description provides enough information to invoke the tool correctly. However, the absence of usage guidance and any behavioral context leaves the description slightly incomplete for an agent that needs to know why or when this affects rendering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage, including an enum of valid engine values and a description for the engine parameter. The tool description adds no additional parameter context, but none is strictly needed given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Set') and resource ('render engine'), making the tool's purpose immediately clear. It does not explicitly differentiate from siblings like blender_render_set_resolution or blender_render_image, but the focus on the engine setting is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool, such as setting the engine before rendering, or when an alternative would be more appropriate. The agent must infer usage purely from the tool name and sibling 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Set the render resolution.' It does not state whether this affects subsequent renders, overwrites existing settings, or requires any scene state. The mutation effect is implied but not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. Every word contributes to the core meaning, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter with a fully documented schema, so the description is minimally viable. However, it lacks any mention of how this setting is used by rendering tools, which would help an agent sequence it correctly. No output schema exists, but for a setter that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already documented in the input schema. The description adds no additional meaning beyond what the schema provides, such as how 'percentage' interacts with width/height or whether all parameters are required. Baseline 3 applies because the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('render resolution'), so an agent can tell this tool is for configuring output resolution. It distinguishes itself from sibling render tools like blender_render_set_engine and blender_render_image by naming 'resolution' explicitly, though it does not elaborate on 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool relative to alternatives, such as whether to call it before blender_render_image or blender_render_animation. No exclusions or preconditions are mentioned, leaving the agent to infer usage from the name and description 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?
With no annotations, the description carries full responsibility for disclosing behavior. It mentions the import side effect, but does not explain polling semantics (e.g., returns immediately with status vs. blocks), what happens if the job is incomplete, whether it can be called repeatedly, or the format of the returned status. This is a significant gap for a status-check 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose and mentions the optional import action. It is concise without being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description should explain what the status response contains and how to interpret it. It also lacks context about typical usage patterns (e.g., polling loop, expected frequency). The description covers the action but not the full operational context needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds no extra meaning beyond what the schema already provides (job_id is from generation, auto_import controls import). Since the schema does the heavy lifting, a 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('check'), a clear resource ('status of an AI model generation job'), and an optional action ('import the completed model'). It clearly distinguishes from generation tools like blender_ai_generate_model and blender_ai_generate_model_sync by focusing on status polling and post-generation import.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. It does not mention that it should be used after blender_ai_generate_model for asynchronous jobs, nor does it contrast with synchronous generation. The relationship is implied by the parameter description but not stated.
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 disclose side effects, but it only states that the mesh is stretched or fitted along the curve. It doesn't say whether the operation modifies the object in place, adds a modifier, requires an existing Geometry Nodes setup, or what the result/return is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with the operation first, behavior second, and use cases last. No filler or repetition; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves important operational context missing: effect on the existing object, modifier behavior, return value, and any prerequisites. The full parameter schema helps, but the operation-level context is not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with useful descriptions, so the baseline is 3. The tool description adds no parameter-level meaning beyond the schema, but it doesn't need to because the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb-resource pair: deform a mesh along a curve using Geometry Nodes, so an agent knows what the tool does. However, it doesn't explicitly distinguish itself from siblings like blender_curve_to_mesh or blender_array_along_curve, only from the general task space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Useful for roads, rails, cables, and profile sweeps' line gives concrete contexts, so usage guidance is more than absent. It never names alternatives or when-not conditions, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 does reveal the workflow (analyzes nodes, extracts color/roughness/metallic, rebuilds a PBR graph), which is useful. But it omits critical consequences: whether the original node tree is destroyed or preserved, what happens to nodes that don't map to PBR parameters, whether textures are retained or discarded, and failure behavior for unsupported materials. For a mutation tool this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, zero filler. The core action is front-loaded in the first sentence and the mechanism in the second, so an agent grasps the operation immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderate-complexity conversion tool with no annotations and no output schema, so the description must carry more weight. It explains the what but not the operational essentials: whether the operation is destructive/reversible, what happens to unmapped or texture nodes, what qualifies as a convertible material, and what the resulting 'clean Principled BSDF setup' structurally looks like (single node vs. node group). An agent cannot fully predict side effects before calling it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; both parameters already have descriptive text in the schema. The tool description reinforces that target_format drives optimization/compatibility of the rebuilt graph, adding marginal context, but it doesn't explain the meaning or effect of each enum value (e.g., what GENERIC implies versus GLTF).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
"Convert a material's existing node tree to a clean Principled BSDF setup" names a specific verb, resource, and outcome. The phrase "existing node tree" implicitly differentiates it from siblings like blender_material_set_principled (fresh setup) and blender_material_inspect_graph (read-only inspection), though it never names them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: use this when a material already has a node tree that needs cleaning up into a standard PBR graph. However, there is no explicit when-to-use/when-not-to-use guidance, no named alternatives, and no mention of prerequisites such as the material needing to exist with a compatible node tree first.
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?
Does not mention that it is a read-only operation, nor does it specify the output format or behavior when no materials exist. Since there are no annotations, the description fails to provide necessary 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple tool, it lacks clarification on what the returned list contains (e.g., names, objects) and whether it includes empty results. Without an output schema, this ambiguity is not resolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema covers all (vacuously). The description adds no parameter-specific meaning, and the baseline for high coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (materials in the file). It distinguishes from other material tools like create or assign, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No indication of when to use this tool versus alternatives, such as before modifying materials or checking existing ones. Lacks context or prerequisites.
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 the full burden of behavioral disclosure. It does state a key behavioral trait — "creates new geometry by extending existing elements outward" — which correctly signals a topology-mutating operation. However, it fails to disclose consequences such as the original elements being moved/replaced, the operation being destructive except via undo, or failure modes when indices don't match the selected mode. The core mechanic is clear, but side effects and risks are left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the verb and resource front-loaded in the first sentence. The second sentence earns its place by framing the operation's nature (creating geometry by extension), though "most fundamental" is mildly promotional. No redundancy with the schema; every clause carries some signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mid-complexity tool (5 params, enum, arrays, 3 required) with no output schema and no annotations, the description is functional but thin. It explains what the operation does, and the schema fills in parameters, but an agent is left without knowledge of return behavior, prerequisites, or how this operation relates to its siblings. Adequate for a basic call; incomplete for confident autonomous selection in a 150-tool environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters adequately, which sets the baseline at 3. The description adds minimal parameter insight beyond reinforcing the offset vector concept in its prose. The relationship between mode=REGION and the 'individual' flag is slightly underspecified even in the schema, but the description neither worsens nor meaningfully improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence uses a specific verb and resource: "Extrude faces, edges, or vertices along an offset vector," which precisely identifies the operation and its target. The second clause, "creates new geometry by extending existing elements outward," conceptually distinguishes extrude from modifying operations like bevel, inset, or dissolve, though it never names a sibling explicitly. In a suite of ~150 tools it could differentiate harder, but the core purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use extrude versus the many sibling mesh operations (bevel, inset, loop_cut, bridge, array_along_curve), and no preconditions are stated (e.g., object must exist, indices must be valid for the mode). The phrase "most fundamental mesh modeling operation" only implies general applicability and does not help an agent select between alternatives. This is a clear gap for a tool in such a large family.
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, yet it only states the basic action. It does not disclose whether the object must be in edit mode, whether the selection replaces or extends the current selection, how open/boundary edge loops are handled, or what happens with an invalid edge_index. These are material behavioral traits for an agent invoking a selection mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the functional information front-loaded. The second sentence ('loops define the flow of geometry') is motivational rather than operational, but it is brief and does not bloat the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The essential calling contract is covered: all three parameters are documented at 100% schema coverage and the operation is described clearly. However, with no annotations and no output schema, the description omits behavioral prerequisites such as edit-mode requirements and selection-combination semantics. For a simple selection tool this is a moderate gap, not a fatal one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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's mention of 'edge loops or edge rings' loosely enriches the ring parameter's meaning, but it adds no syntax, format, or boundary details beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Select') and resource ('complete edge loops or edge rings through a given edge'), which clearly identifies the operation. The loop/ring concept inherently distinguishes it from generic siblings like blender_mesh_select, blender_mesh_select_shortest_path, and blender_mesh_select_trait, though it doesn't name any alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Fundamental for hard surface modeling' provides implied usage context, but there is no explicit guidance on when to choose this tool over the many sibling selection tools (select, select_shortest_path, select_trait, select_linked_flat) or when not to use it. The guidance is suggestive, not directional.
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?
Annotations are absent, so the description carries the full burden of behavioral disclosure. It states that a box collision primitive is created and implies efficiency, but it does not disclose side effects such as whether existing collision data is replaced, whether a new collider object is created, or how collision_type affects the result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The core action and resource are front-loaded, and the efficiency note is a compact, useful addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool in a specialized MSFS collision pipeline with no annotations and no output schema, this description is too thin. It does not explain return values, prerequisites such as whether the object must already exist, interaction with existing collision setups, or how the collision primitive relates to MSFS export validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents object_name, padding, and collision_type, including the enum values. The description adds no additional parameter-level meaning, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('box collision primitive for an object'), and the phrase 'box collision primitive' distinguishes it from mesh-based or convex collision sibling tools. It does not explicitly name sibling tools, but the resource type is clear enough to identify the intended operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical 'most efficient for physics' gives an implied usage hint, suggesting this is the lightweight collision option. However, it does not explicitly state when to choose this over blender_msfs_create_collision_mesh or blender_msfs_create_collision_convex, nor does it provide exclusions or alternative routing.
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 of explaining behavior. It only says 'Create LOD hierarchy' but does not disclose whether it decimates geometry, creates new objects, modifies the base object, renames objects, or replaces existing LODs. The schema hints at decimation through auto_decimate and decimate_ratios, but the description itself omits this 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core action ('Create LOD hierarchy') and then adds the purpose context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that creates objects and may perform decimation, the description is too sparse. With no annotations and no output schema, an agent lacks critical context about what will happen in the scene, what prerequisites exist (e.g., base object must already exist), or how this relates to sibling LOD tools like blender_msfs_decimate_for_lod and blender_msfs_setup_lod_distances.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters. The description adds no additional parameter meaning beyond the schema. It does not clarify how decimate_ratios map to LOD levels or what auto_decimate does in practice, but the schema's examples provide reasonable coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific verb and resource: 'Create LOD hierarchy from a base object' for flight simulator content optimization. It is understandable in isolation, but it does not explicitly differentiate itself from related sibling tools like blender_msfs_decimate_for_lod or blender_msfs_setup_lod_distances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for flight simulator content optimization' implies the intended context, and the name suggests it is for building LOD levels. However, there is no explicit guidance about when to prefer this tool over sibling LOD-related tools, nor any exclusions or prerequisites.
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 impact. It only states the intended effect without explaining whether the overlay replaces existing overlays, requires paint mode setup, or modifies the Blender scene state. This is a significant transparency gap for a state-changing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler. It conveys the core action efficiently and earns its place without redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the one-line description leaves out workflow context that an agent would need, such as whether this should follow template download, whether paint mode is required, and what visual/state change occurs. It is minimally understandable but not fully complete for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 little beyond 'template image', which loosely maps to image_path, but opacity and object_name semantics are only documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Load'), a clear resource ('reference template image'), and the intended purpose ('as overlay for painting'). It does not explicitly differentiate from the sibling blender_reference_image_setup, but the MSFS livery context and 'template' wording clarify the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for painting' implies use during a livery painting workflow, which gives some usage context. However, it does not mention alternatives, prerequisites, or when not to use this tool, especially compared to related tools like download_template or reference_image_setup.
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 behavioral burden but discloses only the UV-remapping mechanism. It fails to mention traits that are evident from the schema: the operation writes files to output_dir, consumes an external source_image, and likely requires aircraft template data — none of which an agent could anticipate as side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single 10-word sentence with the core action front-loaded and zero filler. 'With UV remapping' earns its place by naming the operative mechanism, and every word contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters (four required), no annotations, and no output schema, the one-liner is under-specified: it never states that results are written to output_dir, whether the source image is treated as read-only, or whether the target aircraft must be prepared in the scene first. An agent can identify the tool but cannot predict its side effects or required setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 and the baseline is 3. The description adds only marginal value by confirming that source_aircraft and target_aircraft refer to different aircraft types, but it contributes no format, constraint, or relationship details beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Transfer'), a clear resource ('livery design'), and a distinctive scope ('between different aircraft types') that sets it apart from every sibling livery tool, none of which perform cross-aircraft transfer. The mechanism ('UV remapping') adds useful precision about what the operation entails, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over related siblings such as blender_msfs_livery_map_elements, blender_msfs_livery_export_textures, or blender_msfs_livery_create_paint_layers. The description states only what the tool does, with no conditions, prerequisites, or exclusions to help an agent decide when transfer is the appropriate step.
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 behavioral transparency burden. 'Validate ... structure' implies a read-only checking operation and states the target, but it does not disclose what checks are performed, whether anything is modified, or what a successful or failed validation looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one front-loaded sentence with no filler. It is efficient and scannable, though it sacrifices some useful behavioral context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter validation tool, the description is minimally viable: it identifies the input and the goal. However, with no output schema, it would be more complete if it described the expected result or the scope of validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, package_dir, is fully documented in the schema as 'Path to the livery package', and the description adds no additional parameter-level detail. Since schema coverage is 100%, baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific operation ('Validate'), the resource ('livery package structure'), and the standard ('MSFS compatibility'). It is clear on its own, but it does not explicitly distinguish from closely related siblings like blender_msfs_livery_analyze or blender_msfs_validate_for_export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or alternatives are mentioned. An agent must infer when package validation should be preferred over related livery or MSFS validation tools.
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 the full burden. It discloses the most consequential trait — that apply_results makes positions permanent ('freezes simulation') — hinting at irreversibility. However, it does not disclose that the simulation mutates object transforms during the run, that the operation is compute-intensive, or that apply_results removes rigid bodies, all of which are relevant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with the core action front-loaded. The parenthetical 'freezes simulation' is slightly redundant with 'make the final positions permanent,' but the overall size and ordering are tight and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with full schema coverage, the definition is adequate: an agent knows the frame range and the freeze behavior. It falls short on prerequisites (physics objects required, not stated) and on operational side effects (scene mutates, long compute time), and there is no output schema or annotation to carry that burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents frame_start, frame_end, and apply_results with defaults and meaning. The description adds only the 'freezes simulation' metaphor for apply_results, a useful mental model but not a substantive technical addition beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Run the physics simulation for a frame range.' This clearly separates it from sibling physics setup tools (rigid_body_add, cloth_add, soft_body_add, fluid_quick) that configure physics rather than simulate. It doesn't explicitly name a sibling or scoping exclusion, so it misses the top score, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use the tool or what prerequisites are needed (e.g., rigid body or cloth objects must already exist in the scene). There are no explicit alternatives, conditions, or exclusions. The only implicit cue is that simulation follows physics setup, which is never stated.
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 disclosing side effects. It mentions that MULTIRES 'adds subdivision levels' and DYNTOPO 'enables dynamic topology,' but does not warn about potentially destructive changes to the mesh, whether existing modifiers are affected, whether the mode switch is reversible, or what happens to the object's current state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficient, using two sentences to convey the purpose, supported modes, and symmetry capability. It is front-loaded with the primary action and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, no annotations, and no output schema, the description is not complete enough. It omits important context such as default behavior when mode is not specified, whether the tool requires a previously created object, what side effects occur on existing mesh data, and what the user can expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 small amount of interpretive value, such as 'adaptive detail' for DYNTOPO and 'mirrored sculpting' for symmetry axes, but most of what it says about modes and parameters duplicates the schema definitions rather than providing significant new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Enter sculpt mode with configuration.' It names the three supported modes and symmetry configuration, making the tool's scope understandable. It doesn't explicitly differentiate from sibling sculpt tools, but the 'setup' positioning is reasonably distinct from operations like blender_sculpt_mesh_filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used before performing sculpting operations, but it doesn't explicitly state when to use it versus alternatives or when not to use it. There is no mention of prerequisites such as the object needing to exist or being a mesh, nor any direction to use a different tool for sculpting edits versus setup.
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 of behavioral disclosure. It states that settings are configured and lists categories, but it does not disclose whether changes persist, apply immediately, overwrite existing configuration, require a restart, or how sensitive values like API keys are handled. For a state-changing configuration tool, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action first and then lists the configurable settings in a compact parenthetical. It contains no filler, no repetition, and every phrase contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a fully documented schema, the essential call shape is present. However, the description does not explain the effects or return value, and it misses an opportunity to distinguish configure_backend from set_backend. With no annotations and no output schema, those gaps remain unfilled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already documented in the schema, with backend described as 'Backend name to configure' and config given an example dictionary. Schema description coverage is 100%, so the baseline is 3. The description adds some useful context by naming 'model paths' and 'device' as potential config keys, but most of the content largely paraphrases what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Configure') and resource ('settings for a specific AI backend'), and enumerates the kinds of settings involved: API keys, URLs, model paths, device, timeout. It is understandable on its own, though it does not explicitly contrast with sibling tools like blender_ai_set_backend or blender_ai_list_backends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific AI backend' implies the tool operates on a named backend, so an agent would likely need to know backend names from blender_ai_list_backends. However, there is no explicit when-to-use guidance, and no mention of blender_ai_set_backend as the alternative for selecting the active backend. The usage context is only implied.
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 behavioral burden. It states the action but does not disclose side effects, such as whether calling it multiple times accumulates instances, whether existing instances are replaced, whether the source collection remains unchanged, or what coordinate system and units apply. These are material gaps for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused, front-loaded sentence. The verb and resource appear immediately, and the examples add useful context without fluff. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description provides only basic purpose and use-case context. It is serviceable for a simple call but lacks behavioral guarantees, prerequisites, and explicit routing guidance among the many similar sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds contextual motivation for use but does not clarify array shapes, defaults, or relationships between locations, rotations, and scales beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Place collection instances at specific locations.' It also gives concrete examples of when this is useful, which helps distinguish it from broad operations. However, it does not explicitly differentiate it from related sibling tools like blender_object_duplicate or blender_geonode_scatter_instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'efficient placement of repeated complex objects' implies a clear use case and gives context. But there is no explicit guidance on when not to use this tool or what alternatives to prefer, especially given the many related placement/duplication/scatter tools in the sibling list.
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 of disclosing behavior. It only mentions creating a material but does not describe side effects (e.g., whether it replaces existing materials, applies to selected objects, or configures specific node trees). No return or error behavior is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant information. It efficiently conveys the essential purpose and context without fluff, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for a basic understanding of when to call the tool (creating MSFS glass materials), but it lacks details about expected outputs, failure modes, or prerequisites (e.g., whether a selected object is required). Given the schema covers parameter formats, the overall context is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions for parameters are present and cover all attributes (ior, opacity, tint_color, is_windshield). The tool description does not add additional semantic detail beyond what the schema already provides, so it stays at the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to create a glass material optimized for flight simulator, with concrete examples (cockpit glass, windows). The verb 'create' and the specific domain make the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool compared to other material creation tools (e.g., blender_material_create, blender_msfs_setup_material). It lacks explicit conditions or alternative selection criteria, leaving the agent to infer appropriate usage.
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 of behavioral disclosure. It only says 'Decimate a mesh', which implies mutation, but it does not state whether the operation is destructive/in-place, whether the original mesh is preserved, that the ratio result is approximate rather than exact, or what the tool returns. 'Target' hints at approximation, but key behavioral details 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short declarative sentence with no filler. The action and purpose are front-loaded, and every word contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is minimally viable for a simple decimate operation: the schema covers parameters well and the description clearly states the purpose. However, with no annotations and no output schema, the lack of behavioral detail—such as whether the mesh is modified in place, whether a new object is created, and how approximate the result is—leaves meaningful gaps for an agent that needs to reason about side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters with descriptions and defaults, including the ratio range and boolean flags. The description's use of 'target ratio' lightly reinforces the ratio semantics but adds no new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Decimate'), a resource ('a mesh'), and an intended purpose ('for LOD creation'). It is clear on its face, though it does not explicitly distinguish itself from blender_ai_mesh_decimate or generic decimation modifiers; the LOD context and msfs prefix do most of the differentiation work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for LOD creation' gives a clear contextual signal that this tool belongs in the LOD pipeline, implying when it should be used. However, it does not explicitly state when to prefer it over alternatives like blender_ai_mesh_decimate or blender_modifier_* decimation, nor does it provide any 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 must disclose behavior on its own. 'Get information' implies a read-only operation, but it does not explicitly state that the tool makes no modifications, nor does it cover error handling (e.g., missing hierarchy). It also does not mention what the returned data structure looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action and resource, then specifies the included data. There is no filler or repetition, consistent with concise design.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the basic purpose, but with no output schema and no annotations, it should at least mention expected return information or failure behavior. The absence of these details leaves an agent uncertain about how to interpret results. A 3 reflects a minimally adequate but gapped description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter 'base_name' is already described as 'Base name of the LOD hierarchy'. The main description mentions hierarchy contents but adds no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), resource ('LOD hierarchy'), and the key contents ('vertex counts and distances'). This clearly distinguishes it from sibling tools like blender_msfs_create_lod_hierarchy or blender_msfs_setup_lod_distances, which create or modify hierarchies. No ambiguity exists about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, such as after creating an LOD hierarchy or before decimating. It does not mention prerequisites, context, or exclusions. The agent must infer usage from the tool name 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, so the description carries the full burden of behavioral disclosure. It only says the tool creates paint layer images; it does not disclose whether existing layers are overwritten, whether the operation is destructive, what prerequisites exist, or what side effects occur in the Blender scene or filesystem.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with a parenthetical list of layer types. It front-loads the main action and resource, and every part contributes useful information without filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complete parameter schema coverage, there is no output schema, no annotations, and no description of what the tool returns or where the created images go. Given the specialized MSFS livery workflow, an agent would benefit from knowing prerequisites, side effects, and what a successful invocation produces, none of which are disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters. The description adds value by enumerating the expected layer names (primer, base_color, cheatline, belly, details, decals, weathering, clearcoat), which clarifies what values the `layers` parameter accepts beyond the schema's generic wording.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create paint layer images') and the resource ('paint layer images for livery workflow'), and usefully enumerates the known layer types. It does not explicitly contrast itself with sibling livery tools such as livery_setup_paint_mode or livery_export_textures, so it misses the strongest form of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for livery workflow' gives an implied usage context, so an agent can infer this belongs to livery creation. However, there is no explicit guidance on when to use this tool versus related livery tools like setup_paint_mode, load_template_overlay, or export_textures, and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 using a particle system, which hints at the mechanism, but it does not state whether a new particle system is created, whether existing ones are modified, whether the operation is destructive, or what the final scene structure looks like. This is insufficient for a mutation tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that leads with the core action, provides concrete examples, and summarizes the controllable aspects without waste. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no annotations, and no output schema, the description covers the core function and parameter categories but leaves out important context: expected return value, side effects on the Blender scene, prerequisites (target/source must exist), and how the result appears. It is adequate for basic understanding but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents 100% of parameters with clear descriptions, so the baseline is 3. The description adds only a high-level summary ('count, randomization, and area restriction') that repeats the schema rather than providing deeper detail about how these parameters interact or what values are meaningful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Scatter') and clearly identifies the resource ('objects on a mesh surface') and method ('using a particle system'). The use cases ('bolts, rivets, damage marks, vegetation') make the tool's intent immediately obvious and help distinguish it from geometry-node-based alternatives like blender_geonode_scatter_instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus the many similar scattering or placement tools, such as blender_geonode_scatter_instances or blender_array_along_curve. There is no explicit context, precondition, or exclusion guidance, leaving the agent to infer the appropriate situation from the tool name 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, so the description carries full burden. It discloses the model (SDXL) but does not explain what happens to the generated image (saved? loaded? returned?), any side effects on the scene, prerequisites, or external dependencies. For a generation tool that may alter the Blender scene or require network access, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, front-loaded with the primary action and model. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is too sparse. It does not explain the output format, how the generated image is returned or stored, integration with Blender, or relation to other reference image tools. Missing critical information for an agent to successfully use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptive text. The description adds no additional parameter meaning beyond what schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a concept art/reference image from a text prompt using SDXL, and notes its usefulness for image-to-3D workflows. This distinguishes it from other AI generation siblings like texture or model generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context ('useful for image-to-3D workflows') but does not explicitly name alternatives or specify when not to use it. It does not contrast with similar AI generation tools (e.g., generate_texture, generate_model) or related reference image setup tools.
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 word 'List' implies a read-only operation, and the description discloses the returned status categories. However, with no annotations provided, the description carries the full burden and does not clarify potential side effects, whether external services are queried, or whether the list reflects cached or fresh data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action verb, and uses the parenthetical to compactly convey the returned status categories. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool shape—one optional parameter and no output schema—the description provides adequate return semantics by naming the status categories and listing backends. It could be more complete by clarifying the effect of available_only=false or by referencing related sibling tools, but the core information needed to call the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single boolean parameter is fully described in the input schema, including its default value, so the description adds no additional parameter semantics. The schema already carries the load here, making the baseline score of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'AI model generation backends', and indicates the returned status categories. However, it does not explicitly distinguish itself from related siblings like blender_ai_probe_backends or blender_ai_model_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus related backend tools such as blender_ai_probe_backends, blender_ai_set_backend, or blender_ai_configure_backend. The agent must infer usage from the name and schema alone, and no exclusions or alternatives are mentioned.
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 makes it clear that this is a state-changing preference operation scoped to model generation, which is the core behavior. However, with no annotations, it doesn't say whether the preference persists, whether the backend must already be available/configured, or whether validation/errors occur for unknown backend names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler. Every clause earns its place: the verb, the scoped resource, the purpose, and useful examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter with a clear schema, this is minimally viable. It lacks context about discoverability/validation of backend names and does not reference the related backend-management siblings, so an agent navigating the large toolset gets only partial guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 giving concrete example values for the backend parameter ('comfyui', 'rodin', 'triposr') beyond the generic schema description, though it doesn't elaborate on how prefer_local interacts with the chosen backend.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('set') and resource ('preferred AI backend') and scopes it to model generation, with concrete backend examples. It is clear on its own, though it doesn't explicitly distinguish itself from the sibling blender_ai_configure_backend, so an agent still has to infer the difference from the word 'preferred'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus closely related siblings such as blender_ai_list_backends, blender_ai_probe_backends, or blender_ai_configure_backend. There are no exclusions or alternative conditions, so an agent must guess the right selection 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 the full burden for behavioral disclosure. It does not mention whether the generated texture is automatically applied, whether it overwrites existing materials, whether it is synchronous or asynchronous, or what the tool actually returns. The only behavioral hint is the use of ControlNet guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or repetition. It is front-loaded and quickly conveys the tool purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema and no annotations, this description is too thin. It does not clarify side effects like auto-apply, the return format, or how this differs operationally from similar texture-generation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are already documented in the input schema. The description adds context linking object rendering and ControlNet, but it does not meaningfully go beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the operation and resource: 'Generate a texture from a depth or normal render of a Blender object using ControlNet guidance.' It clearly distinguishes this from other AI texture tools by specifying the render type and ControlNet method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: generating a texture for a Blender object using depth/normal guidance. However, it does not explicitly mention when to use this tool instead of alternatives like blender_ai_generate_texture, blender_ai_inpaint_texture, or the synchronous variants.
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 of behavioral disclosure. It does state a useful action fact ('Creates (or reuses) a wire mesh shape'), which is some behavior beyond the bare action. But it does not disclose whether an existing custom_shape is overwritten, what happens if the bone or armature does not exist, whether the operation is undoable, or any side effects on the scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, tightly written, and leads with the core purpose. The shape list is useful and not redundant with the schema. It earns its place. Minor inefficiency: the list duplicates the schema enum, but it aids quick comprehension without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description should disclose prerequisites (e.g., armature must exist, bone must exist or be created), error behavior, and whether the shape is reused across calls. None of that is covered. The shape list and scale parameter hint are useful, but an agent is left guessing about failure modes and state changes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains every parameter (armature_name, bone_name, shape, scale). The description adds the list of valid shape values, which overlaps with the enum but is still helpful context. With full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Assign'), a specific resource ('custom_shape' on a bone), and the exact purpose ('rig visualization'). It also enumerates the valid shape types, which reinforces what the tool does. It is clearly distinct from sibling tools like blender_constraint_add or blender_armature_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for rig visualization') but does not explicitly say when to use this tool versus alternatives, nor does it mention when not to use it. Among the large sibling set, there is no direct alternative for bone custom shapes, so the lack of exclusion is less damaging. However, no explicit guidance 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, so the description carries the full burden for behavioral disclosure. It states the export action but does not mention file overwriting behavior, whether the operation is read-only with respect to the scene, or the defaults for selected_only and apply_modifiers. This leaves significant side-effect ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource. It contains no redundant words and reads as a clean, efficient summary of the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should carry more weight than it does. Missing details about FBX-specific options, default parameter behavior, and side effects leave the agent with incomplete information for a multi-parameter file-export operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The phrase 'scene or selected objects' lightly reinforces the selected_only parameter, but the description adds no substantive meaning beyond the schema's existing 'Export selected objects only' and 'Apply modifiers' descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Export') with a clear resource ('scene or selected objects') and target format ('FBX'). It differentiates from sibling exporter tools by explicitly naming the FBX format and the scene/selection scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when FBX output is desired. However, it provides no explicit comparison with sibling exporters (gltf, obj, stl, usd) and no guidance on when not to use this format, leaving the agent to infer usage from the tool name 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, so the description carries the full burden of behavioral disclosure. It does not disclose effects on the Blender scene, whether the export overwrites files, whether it is a non-destructive read operation, or whether export failures can leave partial files. For a file-export operation this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short, clear sentence that is front-loaded with the action and resource. It is concise and readable, though it sacrifices a little useful behavioral detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter export tool with no output schema and no annotations, the description is adequate but not complete. It identifies the core operation and the selected-only behavior, but lacks guidance on when to choose it over sibling exporters, file overwrite behavior, and what the tool returns or reports after exporting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 context by mentioning 'scene or selected objects', which maps to the selected_only parameter concept, but it does not explain the differences between GLTF_SEPARATE and GLTF_EMBEDDED or the consequences of disabling materials/animations. It does not go beyond schema descriptions in any significant way.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Export') and resource ('scene or selected objects') with a clear target format ('glTF/GLB'). This distinguishes it from sibling export tools (FBX, OBJ, STL, USD) and import tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates its core use case (exporting to glTF/GLB) but does not explicitly tell when to prefer it over sibling exporters like blender_export_fbx, blender_export_obj, or blender_export_usd. The context is implied by the format name, not 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?
With no annotations, the description carries the full burden of explaining behavior. It does clearly convey the core operation and scope, but it omits details such as file overwrite behavior, coordinate/orientation conventions, or what happens when apply_modifiers is enabled beyond the schema. The description is adequate but not rich in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the essential operation with no wasted words. It is appropriately sized for a relatively simple export tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling set of export tools and the absence of annotations or an output schema, the description is too thin to fully guide an agent. It does not explain when OBJ is preferable, what side effects to expect, or how the tool behaves with existing files, leaving important context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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's phrase 'scene or selected objects' lightly reinforces the selected_only parameter, but it does not add meaningful new meaning beyond what the input schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Export'), a resource ('scene or selected objects'), and the target format ('OBJ format'). It clearly distinguishes this from sibling exporters like blender_export_gltf, blender_export_fbx, blender_export_stl, and blender_export_usd by naming the format explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to choose OBJ over the many sibling export formats, nor does it mention any alternative tools or conditions. An agent is left to infer that this tool should be used when OBJ output is desired, with no exclusions or fallback 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?
With no annotations provided, the description carries the burden of behavioral disclosure. 'Get' implies a read operation, but the description does not state that the tool is non-mutating, what it returns, or whether anything in Blender may change. This is a very thin transparency layer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundancy. It is front-loaded and appropriately sized for a zero-parameter getter, earning its place without wasting tokens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description does not clarify what result is returned, such as a version string, an integer, or a structured object. Since there is no output schema, the description carries some responsibility for specifying the return shape. It is sufficient for a quick invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and a 100% schema coverage for that empty schema, so there are no parameter semantics to describe. The baseline of 4 is appropriate because the description cannot add value on parameters that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get Blender version information.' It is clear and distinguishes this from the many scene/object/render siblings, though it largely restates the tool name and does not clarify what the version information contains beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The intended usage is only implied: call this when you need Blender's version. Because it is a simple zero-parameter probe, the omission is not critical, but the guidance is still only implicit.
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 the burden of behavioral disclosure. It does explain the consequence of marking seams ('define where the UV map is cut for unwrapping'), which is useful. However, it omits operational traits: that this mutates mesh data, that marking only affects UV unwrapping and not geometry, and how clearing interacts with previously set seams.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the action, followed by a clear conceptual explanation and a one-line purpose statement. No redundancy or filler. It could earn a 5 only if the 'Essential for texture mapping preparation' sentence carried more actionable detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple four-parameter tool whose schema is fully documented: the agent knows what the operation is, what UV seams are for, and how to pass parameters. Gaps remain: no guidance on when to choose manual seam marking over automated unwrapping, and no explicit workflow note about selecting edges in the viewport first. Since there is no output schema, the description also doesn't need to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all four parameters including the edge_indices/selected_only fallback behavior. The description adds conceptual background about UV seams but no additional parameter-level meaning, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource pair ('Mark or clear UV seams on edges') and adds conceptual context explaining what UV seams do, which distinguishes it from related edge tools like blender_mesh_mark_sharp or blender_mesh_crease. However, it does not explicitly name sibling tools or state why it differs from them, stopping short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Essential for texture mapping preparation' gives implied usage context for when an agent should reach for this tool. But there is no explicit when-to-use vs when-not-to-use guidance, no mention of alternatives like the auto-UV tool, and no workflow prerequisites (e.g., select edges first or pass edge_indices).
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 of behavioral disclosure. It says 'Select,' which implies a selection-state change, but it does not disclose that selection replaces the current selection unless extend is true, that the operation is non-destructive to geometry, or what happens on no matches. The schema's extend description partially covers selection behavior, but the tool description itself adds little behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a front-loaded verb and resource, followed by a compact enumerated list of traits. 'Essential for finding problem areas' adds practical context without bloat. Every sentence earns its place, though the enumerations partially overlap schema enum values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a moderately simple selection operation with five parameters, and the schema already documents all parameters and enums. The description plus schema is probably sufficient for an agent to call it correctly, but without annotations or output schema it could still benefit from noting that the tool only modifies the active selection and does not report counts or results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 restates trait categories in natural language, which slightly reinforces the enum meanings, but it does not add parameter-level guidance beyond what the schema already provides for face_sides, non_planar_threshold, or extend.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Select mesh elements by geometric trait.' It then enumerates the trait categories (non-manifold edges, boundary edges, loose vertices, interior faces, faces by side count, ungrouped vertices, non-planar faces), which makes the tool's scope immediately clear and distinguishes it from generic selection siblings like blender_mesh_select or blender_mesh_select_edge_loops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Essential for finding problem areas' gives a clear use context, and the trait enumeration implies when to use the tool. However, it does not explicitly compare against sibling selection tools or state when not to use it, so the agent must infer the routing decision rather than being told.
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 of explaining side effects. It only says it creates a convex hull collision mesh; it does not say whether a new object is created, whether the source object is modified, whether existing collision data is replaced, or how collision_type is applied. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. 'Create a convex hull collision mesh' states the action and resource immediately, and the parenthetical adds only the differentiating tradeoff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description alone must enable correct selection and invocation among closely related siblings like create_collision_box, create_collision_mesh, and tag_collision_type. It does not explain when this particular hull type should be created, what happens to the source object, or the meaning of collision_type choices, so key context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents object_name and collision_type, including the enum values. The description adds no per-parameter detail, such as how collision_type affects the generated hull or which value is appropriate in which scenario, so it stays at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and a specific resource ('a convex hull collision mesh'), and the 'convex hull' qualifier plus the accuracy/performance balance distinguishes this from the sibling collision tools like create_collision_box and create_collision_mesh. An agent can tell what this tool does without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(balance between accuracy and performance)' implies this is a middle-ground option compared to box or full mesh collisions, but it does not explicitly state when to choose this over those alternatives or when not to use it. The guidance is contextual but left to inference rather than clearly stated.
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 disclosure burden, yet it only restates the operation itself. It does not disclose that changing an origin shifts transform data and can affect children, constraints, or animation, and it leaves the cursor workflow ambiguous — whether the tool sets the cursor itself or expects the caller to pre-position it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero filler; the parenthetical adds real clarifying value without adding length. Every word earns its place and nothing from the schema is redundantly repeated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a behavioral enum, an optional origin_type whose default is undocumented in both the description and the schema, and a conditional cursor_location parameter. A one-sentence description omits the default origin_type behavior, side effects on transforms/children, and the cursor precondition. With no annotations and no output schema, this leaves agents to guess on the very points that determine correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies; the enum values (GEOMETRY_CENTER, ORIGIN_CURSOR, ORIGIN_CENTER_OF_MASS, ORIGIN_CENTER_OF_VOLUME) are largely self-explanatory. The description contributes only the 'pivot point' gloss and does not clarify the ambiguous cursor_location semantics ('Set 3D cursor here first') or the default behavior when origin_type is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb-resource pair ('Set the origin of an object') plus an in-line clarification of the key term via the parenthetical '(pivot point)'. It is immediately distinguishable from every sibling, especially adjacent ones like blender_object_transform and blender_object_apply_transforms, none of which claim origin-setting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage must be inferred: an agent can reasonably deduce this is the tool to call when an object's origin/pivot point needs repositioning. However, the description names no alternatives, gives no when-not-to-use conditions, and does not explicitly disambiguate against transform-related siblings, leaving the routing entirely implicit.
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 only states what is set, not whether omitted parameters are left unchanged or reset, what coordinate system or units are used, whether values are absolute or relative, or what happens if the object does not exist. For a mutation tool this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or repetition. Every word contributes meaning, and the key action and target are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing tool with no annotations and no output schema, the description is too thin. It does not clarify the behavior of partially specified transforms, units (e.g., radians vs degrees), or error conditions such as a missing object, leaving an agent to guess important invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for name, scale, location, and rotation. The description adds little beyond restating these fields, though the phrase 'and/or' usefully implies that any subset of the transform properties can be provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') with a clear resource ('an object') and explicitly names the three transform properties: location, rotation, and scale. It distinguishes this from sibling tools like blender_object_set_origin or blender_object_apply_transforms by focusing on direct transform assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It is implicitly clear that this tool is for directly setting an object's transform properties, but there is no explicit guidance about when to choose this over related tools like blender_object_apply_transforms, blender_object_set_origin, or blender_mesh_proportional_transform. No alternatives or exclusions 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does state that the tool creates a new action and may assign it to an object, but it does not disclose what happens if the object already has an action, whether the new action becomes the active one, or how omitted optional parameters are handled. These are significant gaps for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. The core operation comes first, the helpful parenthetical defines the domain concept, and the optional assignment behavior is included without extra wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter creation tool with full schema coverage, the description is mostly adequate for basic invocation. However, with no output schema and no annotation context, it does not fully cover side effects of assignment, default behavior when name is omitted, or what the caller should expect as a result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 little beyond the schema: 'optionally assign to object' roughly mirrors the object_name parameter's role, but it does not clarify defaults or constraints beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create'), identifies the resource ('action'), and clarifies the Blender-specific meaning with 'animation data container'. It also states the optional assignment behavior, which distinguishes it from tools like blender_action_list and keyframe tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by 'Create a new action' and the optional assignment to an object, but there is no explicit guidance about when to use this tool versus alternatives, such as when to list existing actions with blender_action_list instead.
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 and does disclose the main behavior: rendering multiple angles, running an Ollama vision model, and returning feedback. However, it does not state whether the operation modifies the scene, what happens if the Ollama server is unreachable, or that multi-angle rendering may be resource-intensive—information an agent would benefit from before invoking it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences front-load the primary behavior and output, then add the refinement context. Every clause earns its place and there is no redundant schema repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action and the high-level return structure, which is important because no output schema exists. Still, with no annotations, six optional parameters, and many overlapping sibling tools, it leaves gaps around target selection, side effects, and external-service prerequisites, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter (prompt, resolution, object_name, etc.) already has a clear schema description. The tool description repeats no parameter details but also does not need to; the baseline of 3 applies because the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Render multi-angle views and analyze with Ollama vision model') and a concrete output (structured feedback with quality score, issues, fix suggestions). This clearly conveys what the tool does, though it does not explicitly position itself against close siblings like blender_render_multi_angle or blender_ai_evaluate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for iterative mesh refinement' implies a use case, but the description gives no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as blender_ai_evaluate or blender_render_multi_angle. An agent must infer when this tool, rather than a sibling, is the right choice.
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 behavioral burden. It clearly states the core behavior—creating a font/text object—but leaves gaps such as object naming, orientation/units, and whether it appears in the active collection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, front-loaded with the action and resource. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterized creation tool, the essentials are present and the schema covers the inputs. It falls short on return value/object name and on disambiguation from the several sibling annotation tools, so a bit more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters, including defaults for size and color, so the description adds no extra parameter meaning. Baseline 3 applies because schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Add a 3D text annotation at a specific location') and clarifies that it creates a font/text object. It is clearly about text annotations rather than generic annotations, but it does not explicitly differentiate from nearby siblings like blender_annotation_add or blender_grease_pencil_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'label or callout' phrase gives an implied use case for when this tool is appropriate. However, it provides no explicit guidance on when to choose this over blender_annotation_add, blender_annotation_dimension, or grease pencil tools.
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 behavioral burden and does disclose the non-destructive, parametric modifier approach. But it never states that the source object itself is mutated in place by adding modifiers, and the verb 'Instance' is ambiguous about whether a new object is created. The apply=true destructive baking is only covered by the schema's parameter description, not the main description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler: the first front-loads the core operation and illustrative use cases, the second adds the mechanism. The em-dash list is information-dense and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Purpose, scenarios, and mechanism are covered, and the schema fully documents parameters, so the tool is callable. But with no annotations and no output schema, an agent must infer whether the source object is modified in place, whether a new object results, and what the call returns — meaningful gaps for verifying success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters (source_object, curve_name, count, fit_type, apply) are already documented structurally. The description adds only the generic notion of 'parametric control' and does not illuminate enum semantics or parameter interactions, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action ('Instance objects along a curve path') and names a clear resource, backed by concrete use cases (rivet lines, bolt patterns, cable runs) and the mechanism (Array + Curve modifiers). It makes the tool's function obvious, but it does not explicitly differentiate from siblings like blender_geonode_array_grid or blender_scatter_on_surface.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The example scenarios imply when an agent should use this tool, and 'parametric control' hints at the trade-off against geometry-node-based alternatives. However, no alternative tools are named and no when-not-to-use guidance is provided, leaving the choice between modifier-based and geonode-based instancing to inference.
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 mentions 'selected to active' which hints at selection state, but that is already in the schema. It does not disclose prerequisites (e.g., UV mapping on the low-poly), side effects (e.g., creation of new image textures, modification of materials), or whether existing images are overwritten. It also does not specify the output behavior beyond the output_dir parameter. Significant behavioral gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and purpose. It is concise and free of redundancy. It could arguably be more compact, but it is well-structured and informative without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, no output schema, and no annotations, the description is insufficient. It explains what the tool does but omits prerequisites (e.g., UV layout, material setup), what happens to the baked maps (e.g., are they saved as image files? assigned to materials?), and any potential side effects. An agent would need to infer these from the schema or trial-and-error, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are described in the schema. The description adds no additional meaning beyond the schema—it does not elaborate on how parameters like cage_extrusion or samples affect the bake. Per the baseline for full schema coverage, a score of 3 is appropriate; the description neither helps nor hinders parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('bake detail from high-poly to low-poly'), the technique ('selected to active'), and the typical use case ('transferring normals, AO, and other maps from a sculpt or subdivision model to a game-ready low-poly mesh'). It distinctly separates this from sibling bake tools like bake_from_multires or bake_to_vertex_colors by specifying the high-poly-to-low-poly transfer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear ideal use scenario and implies when to use it (when you have a high-poly and low-poly pair). However, it does not explicitly mention alternatives or situations where a different bake tool would be more appropriate, such as baking PBR maps in one batch or baking from multires. The guidance is helpful but not fully explicit.
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 optional apply and hide behavior, but does not disclose that this is a destructive/modifying operation on the target object, whether apply=false leaves a live modifier, or what happens if the objects do not intersect. This is a meaningful transparency gap for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action and operation types are front-loaded, and the optional behaviors appear second. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutating tool with no annotations and no output schema, the description is adequate but not complete. It covers the main action and optional behaviors, but leaves out usage guidance, prerequisites, failure implications, and the non-destructive modifier behavior when apply is false.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters including defaults and solver differences. The description adds only light framing by clarifying that target and tool are the two objects involved, but does not provide any meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Perform') and resource ('boolean operation between two objects'), and lists the three operation types. The 'single call' phrasing also distinguishes it from more manual modifier workflows available in siblings like blender_modifier_add and blender_modifier_apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'in a single call', which suggests this is the direct one-shot path rather than a multi-step modifier workflow. However, it does not explicitly state when to prefer this over modifier-based tools, nor does it mention any exclusions or prerequisites such as both objects existing.
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 behavioral disclosure burden, but it only names the affected properties and view layer. It does not explain whether optional flags are left unchanged when omitted, what happens if the collection is not found, or whether 'toggle' means flipping current state versus setting the given values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the action and resource, with no filler or repetition. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The full parameter schema and the 'current view layer' qualifier make the tool mostly usable. However, the missing clarification around optional-boolean behavior and failure handling means it is not entirely complete for an agent invoking it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: each boolean and collection_name has a clear descriptive meaning. The tool description merely restates the property names without adding new parameter-level detail, so the schema baseline holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action—toggle—and a specific resource, collection, and lists the exact properties affected: visibility, renderability, and selectability. This clearly differentiates it from collection_create/list/move siblings, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a useful context qualifier, 'in the current view layer,' which helps an agent infer when it applies. However, it does not explicitly state when to use this tool versus alternatives or mention any prerequisites or exclusions, leaving usage mostly implied.
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 of behavioral disclosure. It discloses the scene-vs-selection scope, which is helpful, but it does not address file overwrite behavior, default values of the boolean options, what happens when export fails, whether the .stl extension is auto-appended, or how non-mesh objects are handled. For an export (write) operation, these are material gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler. 'Export scene or selected objects to STL format' delivers the action and scope immediately, and the parenthetical '(for 3D printing)' earns its place by conveying the intended use case. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter file-export tool with 100% schema coverage and no output schema, the description covers the essentials: what is exported, in what format, and the selected-only scope option. However, with no annotations and no output schema, the description could usefully state defaults or consequences (e.g., overwrites existing file, boolean defaults). The schema handles the parameters, but a bit more behavioral context would make this fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters (filepath, ascii, scale, selected_only, apply_modifiers). Per the baseline rule, the description need not repeat parameter details. The description adds no extra parameter semantics, but none is required given complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Export'), resource ('scene or selected objects'), and target format ('STL format'), with a use-case hint ('for 3D printing'). The format name alone distinguishes it from sibling exporters (blender_export_gltf, blender_export_fbx, blender_export_obj, blender_export_usd) without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The '(for 3D printing)' hint implies when STL is the right format, which is useful implicit guidance. However, there is no explicit when-to-use or when-not-to-use guidance, and no routing to alternative exporters (e.g., 'use glTF for textured web models' or 'use OBJ for interchange'). The agent must infer the right format choice from context alone.
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 the full burden of explaining behavior. It does disclose that a new object is created and notes the geometry node involved, which implies a non-destructive generation process. However, it does not state whether the original profile or curve objects are left unmodified, what happens if inputs are invalid, or how the new object is selected/named beyond the schema's 'name' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, purposeful sentences with no filler. The core action is stated first, followed by the output behavior, then relevant use cases. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose, output, and common applications, and the schema covers all parameters. However, there are no annotations and no output schema, so the description should provide more context about prerequisites, such as needing existing curve and profile objects, whether the operation is destructive to inputs, and how it compares to related sibling tools. These gaps leave an agent with some uncertainty when selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds little beyond the schema, though it reinforces the idea of a profile swept along a path. One minor inconsistency: the description says '2D profile mesh' while the schema says the profile object can be a 'mesh or curve,' which could slightly mislead an agent about accepted profile types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Extrude a 2D profile mesh along a curve path') and names the underlying method ('using the Curve to Mesh node'). It also conveys the result ('Creates a new object') and gives concrete use cases. It does not explicitly differentiate from closely related siblings like blender_curve_to_mesh or blender_array_along_curve, but the intent is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use cases listed ('pipes, railings, moulding, and trim') give helpful context for when this tool is appropriate. However, there is no explicit guidance about when not to use it or which sibling tools might be better alternatives for related tasks such as simple curve-to-mesh conversion or arraying geometry along a curve.
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 burden; it transparently states the core result ('creates a link') and its direction. It does not disclose whether an existing input connection is replaced, socket type compatibility, or failure behavior, so it is only minimally sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler; the primary action and scoping material/shader graph appear first, and the link direction is clarified in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Schema coverage is complete, but for a mutating graph operation with no annotations or output schema, the description omits useful context: valid socket discovery via inspect_graph, prerequisite node/material existence, and replacement semantics. It is adequate for basic invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already documents all five parameters at 100% coverage, so schema does the heavy lifting. Description adds only the output-to-input directionality, consistent with schema, but no extra formatting or value constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action: connect two nodes in a material's shader graph via socket names. Adds directionality (output-to-input), which clearly separates it from siblings like blender_material_node_add and blender_material_inspect_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives; does not mention that the material and both nodes must already exist before linking. The only implied guidance is that this tool performs connections, so an agent would have to infer prerequisites from 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 the full burden of explaining behavioral traits. It says the tool insets faces, but it does not disclose that this modifies the mesh in place, whether it affects face selection, or any prerequisites or side effects. For a mutating geometry tool, this leaves notable behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core action is front-loaded, and the second sentence adds practical use-case value rather than redundancy. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mesh editing tool with no annotations and no output schema, the description covers the essential purpose and typical applications. However, it lacks guidance on selecting it over similar mesh tools and does not disclose behavioral side effects, leaving the definition only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all six parameters thoroughly. The description adds no parameter-level detail beyond the schema, but with full coverage the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Inset faces to create border loops.' It also names concrete use cases like panel lines and window frames, which helps an agent identify when this tool is relevant. It does not explicitly distinguish itself from sibling mesh tools like bevel or loop cut, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical context for when to use the tool: 'Essential for panel lines, window frames, recessed details on hard surfaces.' This is clear use-case guidance, but it does not mention alternatives or when not to use inset versus bevel, extrude, or loop cut, so it is not fully explicit about 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?
There are no annotations, so the description must disclose behavioral traits on its own. It only says 'Select,' leaving unclear whether the selection replaces or extends the current selection, whether edit mode is required, and what happens with invalid indices. This is a meaningful transparency gap for a selection-mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first defines the core action, and the second explains typical use cases. There is no filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is acceptable for a simple selection tool and the schema fully documents the parameters. However, it omits guidance on selection behavior, prerequisites, and side effects, and there is no output schema to compensate. An agent may need to infer important operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 general context about 'mesh elements' and surface paths, but it does not add parameter-level meaning beyond what the schema already provides for index_a, index_b, and mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Select shortest path between two mesh elements.' It clearly conveys what the tool does and adds useful context about edge loops and vertex paths, but it does not explicitly contrast itself with sibling tools like blender_mesh_select_edge_loops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete use cases: selecting edge loops or vertex paths along the mesh surface. It provides clear context for when this tool is appropriate, though it does not mention alternative tools or exclusion conditions.
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 of disclosure. It clearly communicates that the operation permanently alters mesh geometry, which signals destructiveness. It does not mention that applying a modifier typically removes it from the modifier stack or that the operation is generally irreversible except through undo.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. The core action and its permanent consequence are front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is adequate for a basic two-parameter operation, and the schema covers all parameters. However, it omits useful operational details such as that applying typically removes the modifier, that the object must support the modifier type, and what happens on failure or when the modifier cannot be applied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 parameter descriptions 'Name of the object' and 'Name of the modifier' are present but minimal, and the main description adds only general context about applying a modifier rather than clarifying either parameter further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: applying a modifier permanently to mesh geometry. It distinguishes itself from siblings like blender_modifier_add, blender_modifier_configure, and blender_modifier_remove by emphasizing permanence, though it does not name a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'permanently' implies the appropriate use case: when the modifier's effect should be baked into the mesh rather than kept configurable. However, there is no explicit guidance about when not to use it or which alternative modifier operations to prefer.
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 the full burden of disclosing behavior. It is a read-only listing operation, but the description does not explicitly state that it has no side effects, nor does it mention the optional filtering capability or any edge cases like an empty scene. The simplicity of the tool reduces the need for extensive disclosure, but more detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core purpose immediately. It is appropriately sized for a simple listing tool, though it omits any mention of the optional filter parameter, which could be seen as a minor gap.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema, so the description is largely sufficient. The name and description together convey the MSFS-specific context, and the schema covers the parameter. The lack of return format details is acceptable for a listing tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the single optional parameter with 'Filter by object name (optional)'. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'all animation tags in the scene', which is specific and distinguishes it from sibling tools like blender_msfs_add_animation_tag. The name reinforces the MSFS domain, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, such as the adding or configuring animation tags. The description only states what it does, leaving the agent to infer that it is for inspection or verification.
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 of behavioral disclosure. It states that files and folders will be created, but it does not disclose whether existing files are overwritten, whether output_dir must be empty, what filesystem permissions are needed, or what the tool returns after success or failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no wasted words. It front-loads the action, the artifact type, and the key generated files, making it immediately scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and the schema covers all parameters, but it lacks return-value information, filesystem safety details, and context about where this tool fits among the many livery-related siblings. It is minimally adequate but not rich enough for fully confident invocation in an unfamiliar workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 parameter-specific meaning beyond the schema, but all seven parameters already have descriptions in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a precise resource: MSFS livery package folder structure with manifest.json and layout.json. This clearly differentiates it from sibling livery tools like create_paint_layers, export_textures, or validate_package.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies this is the scaffolding step for a livery package, but there is no explicit guidance about when to use it versus livery-related siblings, no mention of prerequisites, and no indication of the intended sequence in the livery creation workflow.
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 the full burden of explaining behavior. It does convey the core operation: reading a livery image and extracting a color palette. It does not disclose the return format, side effects, or how defaults like exclude_white affect results, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. 'Extract color palette from livery image' carries the core action and resource, and 'for recreating designs' earns its place by clarifying the intended workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple extraction tool with fully documented parameters, the description plus schema is minimally sufficient for an agent to invoke the tool. However, there is no output schema and the description does not state what form the returned palette takes or how this step fits into the broader livery workflow, so completeness is only adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already explains image_path, num_colors, and exclude_white. The description adds 'livery image' context but no additional parameter-level meaning beyond what the schema provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation—'extract color palette'—and a specific resource—'livery image'—with a clear intended goal of recreating designs. It is distinct enough from sibling tools like sample_color or livery_analyze, though it does not explicitly name or contrast those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for recreating designs' implies the tool is used when an agent needs to pull reference colors from an existing livery image. However, it provides no explicit when-to-use versus when-not-to-use guidance and does not mention alternatives such as sample_color or livery_analyze.
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 present, so the description carries the full burden of behavioral disclosure. It does disclose a read-only lookup ('Get') and clarifies the domain of the returned data, which is useful. However, it does not mention dependencies, side effects, failure modes, or how results are structured; this is acceptable for a simple zero-parameter getter but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a front-loaded verb and object. 'Get available paint presets for livery painting (layers and brushes)' contains no filler and the parenthetical adds relevant distinction without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema and no annotations, the description is largely sufficient: it states what the tool returns and its domain. It is slightly incomplete because it does not explain how the returned presets should be consumed by sibling livery tools or whether any livery context must be active, but this is a minor gap for such a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there is no parameter documentation burden. The parenthetical '(layers and brushes)' adds useful semantic context about the result categories but does not need to describe parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a clear object ('paint presets'), and scopes the action to livery painting with explicit categories ('layers and brushes'). This clearly communicates what the tool does and separates it from obvious setters/creators like set_paint_brush and create_paint_layers, though it does not explicitly name 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to call this tool versus related livery tools, and no sequencing or prerequisite information. The verb 'Get' weakly implies a query action, but there is no mention of using it before create_paint_layers or set_paint_brush, so the agent is left to infer the intended workflow.
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. The verb 'Get' implies a read-only operation, and the mention of 'texture sizes and UV regions' gives some indication of the returned content, but it does not disclose prerequisites, failure modes, or whether any scene state is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the main purpose and adds specific useful details. There is no wasted wording or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and a clear purpose, so the description covers the basics. However, with no output schema and no usage guidance, the agent is left to infer the exact return structure and how this tool fits into the livery workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for aircraft_id is complete with an example and explanation, so schema coverage is 100%. The tool description adds no additional parameter semantics beyond echoing the schema, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get detailed template information') on a clear resource ('an aircraft') and specifies the key content ('texture sizes and UV regions'). This clearly differentiates it from sibling tools like livery_download_template or livery_load_template_overlay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus related alternatives such as blender_msfs_livery_get_aircraft_templates or blender_msfs_livery_download_template. The intended context is only implied by the wording, with no explicit exclusions or selection 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys that the tool mutates an existing mesh by tagging it, but it does not mention side effects, whether an existing collision tag is overwritten, whether the object must be in the scene, or what the result of the operation is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the core operation and target, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with full schema coverage, the description is mostly sufficient to invoke it correctly. However, with no annotations or output schema, and with nearby sibling tools that could be confused with this one, the description leaves room for clearer guidance on selection and expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema, which places it at the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Tag') and resource ('existing mesh') and clearly communicates that this is a tagging operation rather than a creation operation. This distinguishes it from sibling tools like blender_msfs_create_collision_mesh, blender_msfs_create_collision_box, and blender_msfs_create_collision_convex without needing to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing mesh' implies the tool is for meshes that already exist, providing some usage context. However, it does not explicitly explain when to choose this tool over the collision-creation siblings, nor does it mention any prerequisites 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?
No annotations are provided, so the description carries the full behavioral disclosure burden. It states that cloth simulation is added, but does not disclose what happens if the object already has a cloth modifier, whether the operation is additive or replaces existing simulation settings, or whether any destructive side effects occur. This is a notable gap for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action and then efficiently enumerates the supported capabilities. Every phrase contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of the tool and the complete parameter schema, the description is minimally viable. It conveys the essential operation and supported options, but it does not mention workflow context such as whether simulation playback or baking is required afterward, or how this tool fits with blender_physics_simulate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 mentions categories like material presets, vertex group pinning, collision objects, and wind, which loosely map to parameters, but it does not add meaning beyond what the schema already provides in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('cloth simulation to a mesh object'), specifying the exact purpose. It is immediately distinguishable from sibling physics tools like soft_body_add and rigid_body_add because it explicitly names cloth simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: an agent would infer to use this tool when adding cloth simulation to a mesh. However, there is no explicit guidance about when to prefer this over soft_body_add or rigid_body_add, nor any mention of prerequisites like needing a mesh object to already exist.
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 carries the full burden of behavioral disclosure. It reveals that a Mantaflow liquid or gas simulation is created, but it does not disclose side effects such as whether existing physics settings on the domain or flow objects are overwritten, whether a bake is triggered, or what scene changes the agent should expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the primary action and required objects, then adds the Mantaflow and liquid/gas details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a physics setup tool with no annotations and no output schema, the description is somewhat thin. It explains what is created but not whether simulation baking is included, whether existing fluid settings are replaced, or what the agent should do after calling this tool. The naming and sibling context help, but important operational context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no parameter-specific meaning beyond what the schema provides; domain and flow roles are already defined in the input schema. This meets the baseline but does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Creates') and a precise resource ('fluid simulation setup with a domain and flow object'), and adds a meaningful technology detail ('Mantaflow-based liquid or gas'). It is clearly distinguishable from sibling physics tools like rigid_body_add, cloth_add, and soft_body_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Quick' prefix and 'setup with a domain and flow object' imply the intended use, but there is no explicit when-to-use or when-not-to-use guidance, and no alternative fluid tool is named. The guidance is adequate at an implied level, but the agent must infer when this is the right choice versus a more manual or detailed fluid workflow.
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 discloses a meaningful side effect: bone transforms are stored as custom properties on the armature. However, with no annotations provided, it does not cover important behavioral details like whether an existing pose with the same name is overwritten, whether pose mode is required, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core action, and the next two sentences add useful side-effect and filtering detail. No wasted words or redundant restatements of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description covers the core behavior and storage mechanism but leaves gaps around overwrite behavior, prerequisites, and error conditions. It is adequate for understanding the main action but not fully complete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds a little context by indicating that the saved data includes location, rotation, and scale, and that bone_filter limits which bones are saved, but it does not substantially enrich the parameter meanings beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Save') with a clear resource ('current pose of an armature') and explains the outcome: a named pose stored as custom properties. This distinguishes it well from the sibling blender_pose_library_apply, which is about applying rather than saving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, such as blender_pose_library_apply or the animation/keyframe tools. The description implies a save operation but does not state context, prerequisites, 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 provided, the description carries the full behavioral burden. It usefully discloses that the image is a 'background empty' used as a viewport overlay, implying it is not a normal rendered object. However, it does not mention scene side effects, whether repeated calls stack or replace empties, or file-existence 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary action and resource are front-loaded, and each remaining phrase adds meaningful context about the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with no annotations and no output schema, the description explains the core operation and purpose but omits operational context such as whether multiple calls create multiple empties, how the image path is resolved, and how this tool relates to referencing/calibration workflows. The schema covers the parameters, but the description is not fully self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all five parameters, including the axis enum, defaults, and value ranges. The description adds no additional parameter-level semantics, keeping this at the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Load a reference image') and a concrete resource/role ('background empty for modeling viewport overlay'), with a purpose clause ('for tracing geometry'). It is distinguishable from sibling tools like blender_ai_generate_reference_image and blender_calibrate_from_reference, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context for use is implied through phrases like 'modeling viewport overlay' and 'for tracing geometry', but there is no explicit guidance on when to choose this tool over alternatives or when not to use it. No exclusions or sibling comparisons 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the behavioral effect of each mask type and that 'Optional blur smooths mask edges.' However, it does not disclose that creating a mask typically replaces the existing mask on the object, nor any prerequisites such as whether the object must be a mesh or require sculpt mode.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at roughly three sentences, with the main verb and resource front-loaded in the first sentence and enum semantics following immediately. Every sentence contributes context, though the mask-purpose sentence is explanatory rather than strictly essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameter semantics well for a 4-parameter tool with no annotations and no output schema. Gaps remain: it does not indicate the return value, what happens to a pre-existing mask on the object, or any prerequisites beyond the schema's implicit object_name reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds genuine value: it explains what each mask_type enum value does (CAVITY masks concave areas, ALL fills, NONE clears, RANDOM randomizes) and elaborates blur's effect as smoothing mask edges, going beyond the schema's terse 'Type of mask to create' and 'Number of blur/smooth passes.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create sculpt masks based on topology features,' with concrete detail on what each mask type does (CAVITY, ALL, NONE, RANDOM). Purpose is unambiguous, but it does not explicitly differentiate from related sculpt sibling tools like blender_sculpt_extract_mask or blender_sculpt_face_set_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool is useful by explaining that 'Masks control which parts of the mesh are affected by sculpting operations,' giving the agent contextual understanding of the mask concept. However, there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives such as face sets.
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 disclosure burden. It transparently describes the output behavior (score range 0-1, per-check results, blocking issues) and 'audit' implies a non-destructive read operation, but it never explicitly confirms that the mesh is not modified or that the tool only diagnoses rather than fixes issues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with zero filler: the action leads, followed by a compact enumeration of return values. Every clause earns its place, and the description is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema present, describing the return shape is a useful and necessary substitution. Still, for a 2-parameter tool with no annotations, the description omits read-only confirmation and any routing guidance among the many sibling validation/mesh-analysis tools, leaving a moderate but not severe gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents object_name and the checks parameter, including the default-all-checks behavior and the full enum of check types. The description adds no parameter-level meaning beyond 'comprehensive audit', matching the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Run a comprehensive mesh quality audit') and clearly enumerates the return values: an overall score, per-check pass/fail results, and blocking issues. It does not explicitly differentiate from sibling tools like blender_msfs_validate_for_export or blender_ai_mesh_stats, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'blocking issues that would prevent clean export' phrasing implies a pre-export quality gate, which gives some contextual usage signal. However, there is no explicit when-to-use guidance and no mention of alternatives such as blender_msfs_validate_for_export, blender_ai_mesh_stats, or blender_ai_fix_mesh_issues, leaving tool selection to inference.
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 the behavioral burden. It does disclose the pipeline stages, rough runtime for quick ('15s blob'), and that it returns pipeline status with results from each stage. However, it does not say whether the call blocks or returns an async status to poll, whether it modifies the current Blender scene, or what side effects a full import+cleanup+texture run may have; these are meaningful gaps for a complex pipeline tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the pipeline scope, and every phrase carries information about stages or quality tiers. It is dense but not bloated, and the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a solid high-level overview and parameter-tier guidance, and the schema covers individual parameter meanings. But for an 11-parameter pipeline with no output schema or annotations, it omits the invocation contract: async vs synchronous behavior, how to interpret or poll the returned status, and whether the pipeline will modify the current Blender scene. The overall picture is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters. The description adds some color ('15s blob', 'good single-image', 'best structure', 'part separation') but essentially restates the pipeline_preset enum meanings. It provides no additional syntax, defaults, or cross-parameter guidance beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific end-to-end workflow: reference photo/prompt -> 3D model generation -> import -> cleanup -> UV -> texture -> optional MSFS prep. This clearly identifies the tool's resource and scope, and distinguishes it from the many single-step blender_ai_* siblings such as blender_ai_generate_model or blender_ai_mesh_cleanup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The quality-tier list gives useful internal guidance on choosing quick vs standard vs multiview_quality vs vehicle_components, and the 'full AI pipeline' phrasing implies when to prefer this tool over granular siblings. However, it never explicitly states when to use this tool instead of alternatives like blender_ai_generate_model, blender_ai_mesh_cleanup, or blender_ai_auto_uv; usage is implied rather than stated.
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 carry the burden of behavioral disclosure. It reveals the baking mode but omits important side effects: writing/overwriting a file at output_path, the requirement for UVs, the need for the object to actually have a multires modifier, and any scene-level mutations. This is a bake operation that writes a texture, so these details matter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, no filler, with the core action and map types front-loaded. Every word contributes to understanding the tool's purpose and method.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a write-producing bake operation, the description is too thin. It fails to mention prerequisites like UV maps or an existing multires modifier, what happens to an existing file at output_path, or how the bake behaves if the modifier is missing. The description gives the 'what' but not enough of the 'how to call safely'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 significant parameter semantics beyond what the schema already provides; it only restates map_type (normals/displacement) and object context (multires modifier) already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb (bake), the resource (a Multiresolution modifier), the map types (normals/displacement), and the mechanism (multires bake mode transferring detail from higher subdivision levels). This clearly distinguishes it from sibling bake tools like blander_bake_highpoly_to_lowpoly or blander_bake_curvature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for baking specifically from a Multiresolution modifier using Blender's multires bake mode. It does not explicitly name alternatives or give when/when-not conditions, but the context is specific enough to guide selection among the many bake-related siblings.
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 at all, the description carries the full behavioral burden. It says 'apply preset constraint setups' but does not disclose that this is a mutating operation on the armature, whether existing constraints on the named bones will be removed/replaced, whether the preset modifies bone transforms or only adds constraints, or what happens if bones are missing. The brief per-preset phrases hint at constraint types but not at side effects. No annotation contradiction exists because annotations are absent, but the behavioral disclosure is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one lead sentence plus six short preset labels. Every preset earns its place by conveying a distinct and informative behavior. The only inefficiency is that the preset names in the description partly duplicate the enum values in the schema, though the added behavioral gloss ('pole target', 'foot roll', 'mutual stretch-to', 'two-axis tracking') justifies the redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required parameters and a 100% schema coverage including nested bone mappings, the description plus schema covers the parameter contract well. However, there is no output schema and no annotations, so the agent is not told what the tool returns or whether it reports failures for missing bones — leaving a moderate gap for a mutating rigging operation. The rich sibling list makes the tool's niche clear but the absence of prerequisite info (armature must exist, bones must exist) is noticeable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% documentation coverage, including a detailed per-preset breakdown of the bones object keys in the schema description. The tool description adds the preset taxonomy and per-preset behaviors ('IK with foot roll', etc.), which enriches the agent's understanding beyond the schema. Since baseline is 3 with full schema coverage and the description meaningfully supplements parameter meaning, a 4 is justified. It doesn't reach 5 because it doesn't describe axis format or angle units, leaving some semantics to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Apply preset constraint setups that require multiple coordinated constraints.' It then enumerates six named presets with concise behavioral summaries ('IK chain with pole target', 'two bones with mutual stretch-to'), which clearly distinguishes this tool from the single-constraint sibling blender_constraint_add. It could be stronger by stating the resource type (armature/bones) more explicitly, but the preset taxonomy gives solid differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when a constraint setup requires multiple coordinated constraints, which is effectively the exclusion condition versus blender_constraint_add (single constraint) and blender_autorig_preset (full armature rigging). It does not explicitly name those siblings or state 'use blender_constraint_add for single constraints,' but the contrast is embedded in the first sentence and preset list. The preset names with bone mappings also signal the intended use cases (IK arms, legs, pistons, wheels, doors, turrets).
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 the behavioral disclosure burden. It does add one meaningful behavioral detail: it uses Pillow when available and otherwise falls back to the Blender compositor. It does not disclose output behavior details, such as whether the output file replaces existing files, what happens on unsupported annotation coordinates, or whether the original render is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core action appears in the first sentence, and the fallback implementation note is a useful second sentence. There is no filler or redundant restating of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with nested annotation objects, the combination of the concise description and the thorough schema gives an agent enough to invoke it correctly. The fallback behavior is disclosed, and the schema covers coordinates, types, and defaults. The main gap is that the description does not mention what the tool returns or whether the output path is confirmed, but the absence of an output schema makes this a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter meaningfully. The description contributes some semantic context by naming the annotation types (arrows, circles, rectangles, text), which maps to the type enum, but it does not add material information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Overlay'), a clear resource ('a rendered image'), and enumerates the annotation types offered. It mostly distinguishes itself from the scene-oriented blender_annotation_* and blender_grease_pencil_create siblings by emphasizing 'on a rendered image', though it does not explicitly name those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: apply 2D markup to a rendered image rather than adding Grease Pencil annotations to the 3D scene. However, there is no explicit guidance about when to choose this tool over blender_annotation_add/blender_annotation_text, nor any stated exclusions or prerequisites such as requiring a prior render.
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 carry the behavioral disclosure burden. It only says 'Add' and that location/input values are optional; it does not describe what happens if the material is missing, the default behavior when location is omitted, whether existing nodes are affected, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences, front-loaded with the action and target, followed by useful node type examples. There is no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a node-creation tool, this is largely complete: it defines the action, target, supported node types, and optional settings, while the schema covers all parameter formats. It only omits minor operational details such as default placement and return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameter meaning is already fully documented. The description adds only light context, such as 'optionally set location and input default values' and a few node type examples, but does not provide substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Add') and resource ('a shader node to a material's node tree'), and clarifies it handles any Blender node type. This clearly distinguishes it from sibling material tools like creation, assignment, or texture presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied by the action and the 'any Blender node type' statement, but it does not explicitly name alternatives or state when not to use it. No prerequisites or exclusions 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?
With no annotations present, the description carries the full behavioral burden. It adds one genuinely useful trait — results are in world units — which clarifies the output without referencing Blender's unit system. However, it does not state that measurement is read-only/non-destructive, what the return value looks like, or how the tool behaves when mode-specific parameters (e.g., point_a/point_b for DISTANCE) are missing. The verb 'measure' implies non-destructiveness, but this is never made explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single 15-word sentence that front-loads the action ('Measure') and enumerates every supported measurement type. There is no filler, no repetition of the tool name, and each clause adds information. The 'in world units' qualifier earns its place as the only non-obvious detail an agent would not infer from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a multi-mode tool with six parameters, no annotations, and no output schema, so the description carries a heavy burden it only partially meets. It does not state what the tool returns (a scalar value, a vector for BBOX, or a dict of measurements), which is critical since there is no output schema and an agent needs the result shape for downstream steps. It also does not clarify that object_name is required even in DISTANCE mode or how invalid combinations (e.g., EDGE_LENGTH without edge_indices) are handled. The description conveys what the tool measures but not enough about how to invoke it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies: the schema already documents every parameter, including mode-to-parameter mappings (point_a/point_b for DISTANCE, edge_indices for EDGE_LENGTH, two vertex_indices for VERTEX_DISTANCE). The description adds modest value by listing the mode names in prose and establishing that coordinates and results are in world units, which informs how to interpret point_a/point_b. It does not resolve remaining ambiguities like how many edge indices are required in EDGE_LENGTH mode, but the schema carries most of the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the verb 'Measure' and names four concrete measurement types (distances, bounding box dimensions, edge lengths, vertex-to-vertex distances), making the tool's scope immediately recognizable. These enumerated types implicitly differentiate it from measurement siblings like blender_measure_surface_area, blender_measure_volume, and blender_measure_edge_angle, which cover different quantities. The 'in world units' qualifier further pins down the semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the enumerated measurement modes: an agent can infer this tool handles linear measurements while area, volume, and clearance have dedicated siblings. However, the description never explicitly states when to prefer this tool over blender_measure_surface_area, blender_measure_volume, blender_measure_clearance, or blender_measure_edge_angle, nor does it name them as alternatives. There is no conditional guidance about when each of the four modes should be chosen.
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 the full burden of behavioral disclosure. It clearly states the return value (volume in scene units cubed) and the additional manifold status report, which is useful. It does not mention side effects or prerequisites, but for a read-only measurement tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the primary action and resource front-loaded. It includes the return unit and manifold check without any fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple measurement tool with one parameter and no output schema, the description explains the return value and manifold status, which is adequate for an agent to invoke correctly. It could mention error handling or prerequisites (e.g., object must exist and be a mesh), but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter with a description ('Name of the mesh object to measure'), and the tool description adds no extra meaning beyond that. The parameter is straightforward, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Calculate') and a specific resource ('enclosed volume of a mesh object'), distinguishing it from surface area, clearance, and edge angle tools by the resource itself. However, it does not explicitly name sibling tools, so it stops short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like blender_measure_surface_area or blender_measure_clearance. The description implies it is for volume measurement but does not state conditions, exclusions, or which tool to use for other measurements.
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 the full burden of behavioral disclosure. It does disclose the key mechanism (projection along view/normal onto the target), which is genuine added context. However, it does not state that the operation destructively modifies the target mesh, that only front faces are cut by default (implied only by the cut_through parameter's default of false), or what happens to the cutter object afterward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with minimal waste, and the primary action is front-loaded in the first sentence. There is mild redundancy — both sentences state that projection onto the target occurs — but the second sentence earns its place by specifying the projection axis (view/normal), which is a non-obvious detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter destructive mesh tool with no annotations and no output schema, the description covers the essential what and how but leaves gaps: the default front-faces-only behavior is never stated, the destructive/irreversible nature of the cut is not confirmed, and there is no mention of prerequisites (e.g., cutter positioning or view alignment despite 'view/normal' implying the current viewport orientation matters).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented in the schema, giving a baseline of 3. The description adds a small amount of relational meaning by explaining that the cutter is projected onto the target, but it does not add syntax, naming, or constraint details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Project a curve or mesh outline onto a target surface to cut panel lines.' It also reveals the distinct mechanism ('projected along the view/normal'), which separates this from sibling cutting tools like blender_mesh_bisect or blender_boolean_op that operate via plane or volume intersection. An agent can tell what this tool does without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to cut panel lines' implies a use case, and the projection mechanism implies when it would be preferred over boolean/bisect operations, but there is no explicit when-to-use or when-not-to-use guidance, and no sibling alternatives are named. The guidance is implied rather than 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?
With no annotations, the description must carry the behavioral disclosure burden. It does communicate that the tool merges vertices and supports different positional strategies and a distance threshold, but it omits important effects such as whether only selected vertices are affected, whether the mesh is destructively modified, and how topology or UV data are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence plus a compact mode list. It front-loads the core action, includes useful use cases, and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with full schema coverage, the description leaves a functional gap: it does not explain how vertices are targeted when vertex_indices is omitted, how the merge modes interact with selection, or what happens when no indices are supplied. For a destructive mesh operation with no annotation safety profile, this is not enough context to invoke the tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% parameter description coverage, so the baseline is 3. The description's mention of merge modes and distance threshold lightly reinforces the schema but does not add new meaning beyond what the enum and parameter descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and target ('Merge vertices together'), then lists concrete use cases and the supported merge modes. This clearly distinguishes it from sibling tools like blender_object_join, which merges objects rather than vertices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use cases 'close gaps, join geometry, remove doubles' imply when the tool is appropriate, but it does not explicitly state when to prefer this over alternatives like blender_object_join, blender_mesh_dissolve, or blender_mesh_bridge. No exclusions or alternative routing 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?
With no annotations, the description bears the burden of disclosing side effects. It only states 'Add a modifier' without mentioning that it modifies the object's state, potential irreversibility, or any prerequisites. This lack of behavioral detail could mislead an agent about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant information. It is well-structured and to the point, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and the presence of sibling tools, the description is largely complete for basic use. It lacks details on preset configuration and potential side effects, but these are not critical for understanding the core purpose. The absence of an output schema is acceptable as no return value is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description adds 'optional preset configuration' which is not fully detailed in the schema, but it does not clarify how this relates to the parameters (e.g., use_preset). The schema descriptions provide basic meanings, but the tool description does not enhance understanding of parameter interactions or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('a modifier to an object'), making the tool's purpose immediately understandable. It also hints at an optional preset configuration feature, adding specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives like blender_modifier_configure or blender_modifier_apply. However, the name 'add' and the context of sibling tools imply the appropriate use case, but it lacks explicit guidance.
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 disclosure burden. The verb 'Get' implies a read-only query with no side effects, which is helpful, but the description does not specify the exact return format, whether results depend on scene state, or what kinds of 'recommendations' are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundant phrases. It is front-loaded with the core action and resource, making it easy to scan and parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of return-value information, but it only says 'settings and recommendations' without elaborating on format, contents, or how the results are structured. For a parameterless getter this is acceptable but still somewhat incomplete for an agent that needs to interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter behavior. The baseline for a parameterless tool is 4, and the description's mention of 'settings and recommendations' provides reasonable context for what the agent will receive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get') and resource ('available flight simulator export settings and recommendations'), so it is not a tautology. It is reasonably clear what the tool returns, though it does not explicitly differentiate itself from sibling MSFS tools like blender_msfs_export_model or blender_msfs_get_material_presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent would call this when it needs available MSFS export settings or recommendations before exporting. However, there is no explicit guidance about when to prefer this tool over related MSFS tools, and no exclusions or alternative tool names 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It reveals only that an image is produced; it does not mention file-overwrite behavior, output format derivation, prerequisites such as an existing UV map, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single focused sentence with no filler; the verb and outcome are front-loaded. It is concise but stops short of providing structured context that would make it richer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with no annotations and no output schema, the one-sentence description is minimally adequate but incomplete. It does not explain how the output image is written, what controls the result, or what state is required on the Blender object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter (object_name, output_path, resolution, fill_opacity, line_thickness). The description adds no parameter detail beyond the general purpose, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Export UV layout') and resource ('UV layout as an image'), with an explicit purpose ('painting reference in external editors'). This distinguishes it from nearby livery tools like blender_msfs_livery_export_textures, which handle actual textures rather than a UV layout image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for painting reference in external editors' gives a clear context for when this tool is appropriate. It does not explicitly name alternatives or exclusions, but the intended use case is unmistakable.
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 carry the behavioral burden. It discloses the precondition that the file must already have a filepath, which is useful, but it does not explicitly mention that the operation overwrites the current file or what happens if called on an unsaved file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the core action first and the prerequisite second. Every sentence earns its place with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter save operation, the description is largely complete: it names the action, the target, and the key precondition. It omits minor details such as return values or explicit overwrite behavior, but those are low-risk for an agent invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% and the single compress parameter has a clear description. The description adds no parameter-level information, so the schema carries the meaning, matching the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (save) and resource (current Blender file), and clarifies the operation is limited to files that already have a filepath. This makes it distinguishable from the sibling blender_save_as, though it does not name that alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The filepath prerequisite gives a clear condition for invocability but does not explicitly state when to choose this tool over blender_save_as or how to handle an unsaved file. Usage context is implied rather than spelled out.
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 behavioral disclosure burden. It does explain how auto-smooth works (edge angle threshold keeps sharp edges flat), adding value beyond the schema. However, it does not mention preconditions beyond object_name describing a mesh, what happens if auto_smooth_angle is supplied with FLAT or SMOOTH, or what side effects/return behavior to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first states the action clearly, and the second adds a valuable rationale for auto-smooth. Information is front-loaded and every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter setter with a fully documented schema, the description is largely complete. It covers the operation, the three modes, and the auto-angle behavior. The main gaps are the lack of return/response details and explicit edge-case behavior, but these are minor for a straightforward shading tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the baseline is 3. The parameter descriptions already define shade_type, object_name, and auto_smooth_angle. The description adds conceptual context for auto-smooth but does not enrich parameter semantics meaningfully beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set smooth, flat, or auto-smooth shading on an object.' It clearly distinguishes this as a shading operation, and the three modes leave little ambiguity. It does not explicitly differentiate from related mesh-edge tools like blender_mesh_mark_sharp, but the purpose is still unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case by saying auto-smooth is 'essential for mechanical surfaces,' which gives some guidance for choosing AUTO. However, it does not explain when to prefer SMOOTH vs FLAT or mention any alternatives or exclusions. Usage guidance is contextual but not explicit.
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?
The description does not disclose any behavioral aspects such as side effects, read-only nature, or edge cases. Without annotations, the user must infer that listing actions is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words, directly stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation, the description sufficiently conveys the core purpose. It does not explicitly mention the return format, but given the tool name and the context of sibling tools, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to explain them. The schema coverage is 100% (empty), and no additional information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear imperative verb ('List'), a specific resource ('actions'), and a scope ('in the Blender file'), leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternative list operations (e.g., blender_object_list). The description is purely functional without 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 must carry the behavioral burden. It does disclose the external Ollama vision dependency and the return of structured scores and suggestions, but it omits operational details such as requiring a running Ollama server, network/performance implications, or likely failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The core action, scope, method, and return type are all front-loaded, and every phrase contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should describe the return shape in more detail, the optional reference_image comparison behavior, and external service requirements. It covers the basics but leaves meaningful gaps for an agent deciding whether and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all six parameters. The description adds only the high-level notion of category-specific criteria, which maps to the category enum, but it does not add meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description names a specific verb ('Evaluate'), a concrete resource ('any render or output'), and the evaluation method ('Ollama vision with category-specific criteria'). This clearly separates it from generation/refinement/validation tools in 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in the context of evaluating outputs, especially after rendering or generation, but it does not explicitly state when to prefer this tool over alternatives like blender_ai_refine, blender_analyze_viewport, or blender_validate_mesh_quality. No exclusions or alternative routing 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, so the description bears the full burden of behavioral disclosure. It discloses blocking/waiting and the return value, but it omits the important default side effect that auto_apply=true will modify the target object's material, and it says nothing about timeout or failure behavior. This is a significant transparency gap for a generation tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the core information: the operation, the synchronous behavior, and the return value. There is no filler, repetition, or schema duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema and no annotations, this description is adequate but thin. It communicates the main blocking behavior and return value, and the schema covers parameter documentation, but it does not mention the default auto-apply mutation, timeout behavior, or failure modes. This makes it workable but incomplete for fully informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline applies; all seven parameters including defaults and enums are already documented in the schema. The description adds no additional parameter-level meaning beyond framing the output as PBR texture file paths.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: generate a PBR texture, wait synchronously, and return texture file paths. This clearly conveys what the tool does and distinguishes it from asynchronous or non-PBR texture generation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended usage context clear: use this tool when you need a blocking synchronous generation call that returns paths when done. It does not explicitly name an async alternative or state when not to use it, but the synchronous framing is a clear contextual signal.
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 bears the full burden of behavioral disclosure. It does disclose the mutating nature and enumerates the concrete effects (removing geometry, merging vertices, recalculating normals), which is genuinely transparent about the operations an agent should expect. It stops short of warning that these removals are destructive and irreversible — no mention of in-place modification or whether the object can be restored — which matters for a tool that deletes geometry.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler: the first front-loads the verb and resource and enumerates the operations; the second supplies the pipeline context. Every clause earns its place, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description covers the core purpose and pipeline position, and the schema fully documents all six parameters. It omits a few useful details — behavior when object_name doesn't exist or isn't a mesh, reversibility, and how status/results are reported — but these are moderate gaps for a cleanup whose operations are largely self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: every parameter already carries a clear description with its default value, so the baseline of 3 applies. The description adds only mild reinforcement by listing operations (remove doubles, fix normals, remove loose geometry, remove degenerate faces) that map to the boolean parameters, but it contributes nothing new about merge_distance's units or edge-case behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Clean up a generated mesh') and enumerates the exact operations performed (remove doubles, fix normals, remove loose geometry, remove degenerate faces), which map directly to the tool's boolean parameters. It also anchors the tool in a pipeline stage ('post-processing step after AI model generation'), which separates it from generic mesh-editing siblings. It loses the top score because the near-duplicate sibling blender_ai_fix_mesh_issues is never explicitly differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions the tool as the 'essential post-processing step after AI model generation,' giving the agent a clear, concrete signal for when in a workflow to invoke it. However, it never names alternatives or states when NOT to use it; with close siblings like blender_ai_fix_mesh_issues and blender_ai_mesh_optimize present, the lack of exclusion guidance prevents a 5.
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 burden of explaining behavior. It does list the four operations performed, which is a strong behavioral signal. However, it does not disclose whether the original mesh is mutated in place, whether existing UVs are overwritten, or whether decimation destroys original geometry detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler: the first sentence names the pipeline and its stages, and the second gives the intended use case. Every word contributes to selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter wrapper tool, the schema fully documents parameters and the description covers purpose, so an agent can select it and set the right toggles. Missing details include side effects, return behavior, and explicit routing to individual step tools when only part of the pipeline is needed, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all six parameters. The description adds only a high-level mapping of pipeline stages to the toggle parameters (cleanup, decimation, auto-UV, normal smoothing) without giving extra parameter-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses an active verb ('Run'), names the resource ('a mesh'), and enumerates the exact pipeline stages: cleanup, decimation, auto-UV, and normal smoothing. Calling it a 'convenience wrapper' and noting 'in one call' distinguishes it from the individual blender_ai_mesh_* step tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context by calling it a 'Convenience wrapper for post-generation processing,' implying it is the one-call choice after generation. However, it does not explicitly state when to prefer the individual cleanup/decimate/auto-UV tools instead, nor does it name any 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 carries the behavioral burden. It clearly communicates the retopology operation and the controls involved, but it does not disclose that remeshing may destructively replace existing topology, UVs, or other mesh data, nor does it clarify how parameters interact when method is SMOOTH versus VOXEL.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, efficient sentences with the core operation front-loaded. Every sentence earns its place: what it does, what it controls, and when it is useful. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and use case, and the schema covers parameters thoroughly. However, with eight parameters, no output schema, no annotations, and close sibling tools, the description lacks explicit guidance on method-parameter interplay (e.g., which parameters apply to VOXEL vs SMOOTH) and how to choose this tool over blender_sculpt_remesh_voxel.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all eight parameters with meaningful descriptions. The tool description adds only a high-level grouping (voxel size, octree depth, smoothing), which maps to the parameters but does not provide additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Retopologize a mesh'), names the two methods (VOXEL or SMOOTH), and gives a clear use case ('converting AI-generated meshes to clean topology'). It does not explicitly distinguish this tool from the closely related blender_sculpt_remesh_voxel sibling, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear intended context: it is useful for AI-generated meshes that need clean topology. However, it does not mention when not to use it or name alternative tools such as blender_ai_mesh_cleanup or blender_sculpt_remesh_voxel, so it lacks explicit exclusion guidance.
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 burden of disclosing that this is a mutating operation; it clearly says 'Add a constraint,' which is transparent and not misleading. It does not disclose whether existing constraints are preserved, what happens when targets are missing, or what is returned, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the action and resource, the second lists supported types and the key selection rule. The most important usage guidance is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The descitionate is reasonably complete for a lean tool description given that every parameter has a schema description, but it does not explain how to structure the nested settings object for different constraint types, what armature_name is required for bone constraints, or what the tool returns on success/failure. Since there is no output schema and no annotations, those gaps make it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 and the description does not need to repeat schema docs. It adds some value by clarifying the bone_name vs object_name selection and mentioning type-specific settings, but it doesn't meaningfully elaborate on the settings keys, target relationships, or armature_name necessity beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Add a constraint') with a clear resource ('to a bone or object') and enumerates the supported constraint families. This distinguishes it from siblings like blender_constraint_preset and modifier tools even without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives useful context by saying to specify bone_name for bone constraints and object_name for object constraints, then points to target and type-specific settings. However, it does not not mention when to prefer alternatives such as blender_constraint_preset, nor does it explain the armature_name requirement for bone constraints or exclude the case where both bone_name and object_name 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?
With no annotations provided, the description must carry the behavioral burden, and it does convey the main side effect: a new curve object is created from the supplied control points. However, it does not disclose scene-level effects such as object naming, placement defaults, or return behavior, leaving gaps for an agent to infer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy: the first states what the tool creates and its input, and the second justifies when curves are useful. It is front-loaded with the operation and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter creation tool with no annotations or output schema, the description is adequate but not complete. The schema compensates for parameter details, yet an agent still lacks explicit information about the result of the operation or how the new curve integrates with the current scene/collections.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all seven parameters with 100% coverage, so the baseline is 3 because the description does not add parameter-specific detail. It only reinforces the 'control points' concept already present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Create') and resource ('a Bezier, NURBS, or Poly curve...from control points'), which is enough to understand what the tool does. It does not explicitly reference sibling tools like blender_curve_from_mesh_edge or blender_curve_to_mesh, so sibling differentiation relies mostly on the 'from control points' phrase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives concrete use cases ('smooth profiles, body panels, pipe routing, and organic shapes'), providing clear context for when curve creation is appropriate. It does not offer exclusions or explicitly point to alternative mesh/curve tools, so it stops short of full when/when-not 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 must disclose side effects and behavior on its own. It does not say whether the original mesh is modified, whether a new curve object is created, or what happens with non-contiguous or unsorted edge indices. 'Extract' implies creation, but the behavioral contract is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: one sentence states the core action, and a second sentence frames practical use cases. There is no filler or redundant schema repetition, and the key behavior is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that mutates scene state, the description is adequate but incomplete. The parameters are fully covered by the schema and the purpose is stated, but the description omits important operational details such as whether the tool creates a separate curve object, whether source mesh remains unchanged, and what happens when edge_indices describe disconnected edges.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the JSON schema already documents all three parameters. The description adds the useful context that edge_indices are used to derive curves along existing geometry, but it does not add meaning about curve_type ordering, expected index format, or edge connectivity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Extract') and a specific resource ('curve from mesh edge indices'), which clearly distinguishes it from sibling tools like blender_curve_create and blender_curve_to_mesh. The added use cases further reinforce what the tool accomplishes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: creating curves that follow existing geometry for pipe routing or profile extraction. It does not explicitly name alternatives or say when not to use it, but the 'from mesh edge indices' framing makes the intended context reasonably clear.
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 present, so the description carries the full transparency burden. It does disclose arbitrary execution, full API access, and the 'result' variable return contract, but it never warns about potential destructive or irreversible scene changes, undo behavior, or failure/error handling, which are important for an arbitrary-code-execution 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler: scope first, then capability, then the return contract. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-complexity arbitrary-script tool with no output schema and no annotations, the description covers the basic call contract and return mechanism. However, it lacks guidance on when to use this tool versus the many specialized siblings and does not explain what happens on script error or timeout, which are meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 useful context about importable modules and setting a 'result' variable, but it does not meaningfully expand on timeout semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Execute arbitrary Python/bmesh script in Blender's context.' It clearly distinguishes this tool from the many specialized mesh/object/modifier siblings by emphasizing arbitrary script execution and full Blender API access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'arbitrary' implies this is the general-purpose fallback, and the mention of real mesh modeling hints at when it could be useful. However, it never explicitly says to prefer specialized tools like blender_mesh_extrude or blender_object_create for routine operations, nor does it describe when not to use this tool.
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 behavioral disclosure burden. It does disclose the key side effect that a Geometry Nodes modifier is applied to object_name, which is meaningful, but it does not clarify whether an existing modifier is replaced, whether other scene state changes, or what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler and front-loads the core purpose and available arrangement types. The side-effect note about object_name is concise and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is adequate for a straightforward tool: the purpose is clear and the schema covers all parameters. However, with no annotations and no output schema, plus a large sibling set, the description would benefit from explicit usage guidance and a note about return values or behavior when the modifier already exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all nine parameters with descriptions and defaults. The description adds little beyond confirming the modifier target, which matches object_name; it does not introduce additional parameter semantics or usage detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific operation: instancing an object in LINEAR, GRID_2D, RADIAL, or HEXAGONAL arrangements via Geometry Nodes. It distinguishes itself from siblings like blender_array_along_curve or blender_geonode_scatter_instances by naming the exact pattern modes and confirming the modifier is applied to object_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for parametric array patterns, and the listed arrangement modes give some context for when this tool fits. However, it does not explicitly contrast with alternatives such as blender_array_along_curve, blender_geonode_scatter_instances, or blender_collection_instance, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the whole burden of behavioral disclosure. It does state 'non-destructive repositioning', which is a meaningful safety trait, but it does not cover details such as behavior on boundary edges, the fact that factor=0 means 'no change', or whether the effective result may depend on selecting edge loops versus single edges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly two sentences, with the primary action front-loaded and the 'non-destructive' clarification as a single follow-up. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers all parameters, and the description defines the operation, which is decent for a simple editing command. However, there is no output schema and no annotations, so the description should at least hint at when this is appropriate relative to alternatives or what 'slide along connected faces' implies for edge selection. That missing usage context leaves it just adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters already have a description in the schema (coverage 100%), so the baseline is 3. The description itself adds no extra parameter meaning (like what a positive factor does relative to face orientation), so it does not push above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: slide edges along connected faces, with an explicit purpose of fine-tuning edge loop position. The 'non-destructive' qualifier further disambiguates it from destructive mesh operations like booleans or deletion, making it distinct from siblings such as extruding or loop cutting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to fine-tune edge loop position' implies a usage context of interactive adjustment, but there is no explicit guidance on when to prefer edge_slide over related tools like blender_mesh_loop_cut or blender_mesh_dissolve. No alternatives or exclusions are named.
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 carries the full behavioral burden. It states the core behavior and supported fill methods, but does not disclose that the operation mutates the mesh, what conditions cause failure (e.g., invalid or non-boundary edge indices), or whether the result is reversible. For a geometry-modifying tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the action is front-loaded and the method list is useful. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is fully self-describing and the purpose is clear, so the tool is minimally callable. However, the description omits side-effect and failure-mode context needed for dependable use, and there is no output schema to clarify return behavior. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents object_name, edge_indices, fill_type, and use_beauty. The description's mention of n-gon, triangle fan, and grid fill paraphrases the enum without adding new semantic detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource ('Fill boundary edges with faces') and adds synonyms ('cap holes, close open geometry') that make the intent unmistakable. This clearly differentiates it from sibling operations like bridge, dissolve, or extrude.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'cap holes, close open geometry' establishes clear context for when the tool should be used. It does not explicitly name sibling alternatives or exclusion criteria, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 of explaining side effects. It communicates the core flattening behavior but does not disclose that vertex positions are permanently modified, whether it operates only on the supplied vertex_indices vs. current Blender selection, or what happens to the mesh after the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero filler. The action is stated first, followed by concrete, useful examples; nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter operation with fully documented schema fields, the description is adequate but has gaps. It does not clarify that vertex_indices, rather than the current Blender selection, defines 'selected vertices', nor does it describe the operation's return value or the fact that the mesh is modified in place.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented in the schema. The description adds no meaningful detail about object_name, vertex_indices, or plane beyond what the schema provides, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Flatten selected vertices to a plane') with a clear resource and domain. The use cases ('clean up bumpy surfaces, create perfectly flat areas') make the tool's purpose immediately understandable and distinguishable from the many other mesh editing 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: flattening bumpy surfaces or making flat body-panel regions. It does not explicitly name alternatives or exclusion conditions, but the use-case framing is enough to guide an agent toward this tool.
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 behavioral burden. It does disclose the primary effect—creating a mesh object from raw data—and the API method used, which is useful. However, it does not describe side effects on the current scene, validation of vertex/face data, or what happens on failure, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with the action and data source front-loaded. There is no filler, and the 'procedural geometry' note adds useful context without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters are documented in the schema, and the description clearly frames the tool's core purpose. Given the absence of annotations and output schema, though, the description does not fully cover contextual details such as whether the new object is added to the active collection, how invalid mesh data is handled, or what the agent should expect as a result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter schema already documents all six parameters. The description reinforces the meaning of vertices and faces through 'raw vertex/face data' but adds no new information about edges, location, or smooth_shade beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create'), a clear resource ('mesh object'), and the precise data source ('raw vertex/face data'). It also names the underlying API method mesh.from_pydata(), which makes the intent unambiguous and distinguishes it from siblings like blender_curve_to_mesh or blender_object_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
'Useful for procedural geometry' provides an implied use case, but there is no explicit guidance about when to use this tool versus the many sibling mesh tools, and no exclusions or alternative routing. The description gives some context but leaves the agent to infer the boundary between this and other creation/modification tools.
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, but it only states that a material gets created and does not disclose side effects such as whether the material is assigned to an object, what happens if material_name already exists, or how the day/night emission is implemented. The schema hints at behavior but the description does not confirm it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with zero redundancy. It states the action, target domain, and typical use cases in 11 words, so every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Together with a fully described schema, the description is workable for a simple material-creation call. It leaves gaps around prerequisites and side effects, and there is no output schema, so an agent still has to infer some behavior from the tool name and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured schema already documents all five parameters. The description adds no additional meaning to base_color, emissive_color, emissive_strength, is_day_night, or material_name; the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: creating an emissive/light material for flight simulator. The parenthetical '(gauges, displays, lights)' plus the 'emissive' qualifier makes it distinguishable from sibling tools like blender_msfs_create_glass_material and blender_material_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical examples give clear usage context: gauges, displays, and lights are self-illuminated surfaces. It does not explicitly name alternatives or state when not to use it, but the context is strong enough for an agent to route to it.
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 behavioral disclosure burden. It does disclose output format (MSFS-compatible glTF) and included categories (LODs, collision, animations), which is meaningful. However, it does not mention overwrite behavior, prerequisites, validation needs, or what happens when objects are omitted, leaving several behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every phrase contributes meaning: the verb, the MSFS target, the glTF format, and the specific included data types. It is as concise as possible while still distinguishing the tool from generic exporters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter MSFS pipeline tool with no annotations and no output schema, the description is adequate but thin. It does not mention preparation steps such as creating LOD hierarchies, collision meshes, or validating the scene before export, nor does it explain the relationship to sibling tools like blender_msfs_validate_for_export, so an agent may miss important workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all parameters already have clear descriptions with defaults and enums. The description's mention of LODs, collision, and animations loosely mirrors three boolean parameters but adds no parameter-level detail beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Export') with a clear resource ('model(s)') and a distinctive target format ('flight simulator-compatible glTF'), and it names the included contents (LODs, collision, animations). This clearly differentiates it from generic export siblings like blender_export_gltf or blender_export_obj.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The MSFS qualifier and inclusion list imply this is the MSFS-specific export path among many generic export tools, but there is no explicit when-to-use/when-not-to-use statement. It does not point to alternatives such as blender_export_gltf or preparation tools like blender_msfs_validate_for_export, so an agent must infer context from the name and sibling set.
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 alone must convey behavioral traits. The verb 'Get list' strongly implies a read-only, non-mutating operation, but the description does not explicitly state that it has no side effects or that it requires no setup. It also does not disclose whether the list comes from local data or an MSFS installation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that delivers the core function plus illustrative examples. There is no wasted wording, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter retrieval tool, the description is nearly complete: it states what is returned (a list of presets) and gives examples. Since no output schema exists, a bit more detail about the exact return format or how the presets relate to sibling setup tools would improve completeness, but the current description is sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the description has no parameter burden to carry. The examples (vehicle_paint, chrome, glass) add useful semantic context about the values returned, which is a small bonus beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get list') and resource ('available flight simulator material presets') with concrete examples (vehicle_paint, chrome, glass), making the tool's function clear. It is implicitly distinguished from sibling material tools like blender_msfs_setup_material, but it does not explicitly name any alternative or contrast behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving preset options, likely before configuring materials, but it gives no explicit when-to-use guidance or exclusion criteria. It does not mention alternatives or conditions under which a different material-related tool should be selected.
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 of behavioral disclosure. 'Sample' implies a read-only, non-destructive action, and the tool's purpose is stated, but the description does not mention output format, color space, coordinate origin, or failure behavior. This is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the core operation is front-loaded before the purpose. Every word contributes meaning, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and complete parameter schema, the description is minimally viable: an agent knows what to invoke and why. However, with no output schema and no annotations, the missing details about the returned color value and coordinate convention leave a clear gap for fully correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with descriptions, so the baseline is 3. The tool description adds only the contextual framing of 'specific coordinates' and 'matching reference livery colors' but does not explain coordinate units, origin, or image format expectations beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation—sampling a color from an image at given coordinates—and ties it to a concrete use case: matching reference livery colors. This clearly distinguishes it from siblings like blender_msfs_livery_extract_colors, which operate on the whole image rather than a single point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case 'for matching reference livery colors' implies when the tool is useful, but the description does not explicitly contrast it with alternatives such as livery color extraction or livery analysis. An agent can infer the context but is not given a clear when-to-use versus when-not-to-use rule.
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?
There are no annotations, so the description carries the full burden. 'Create' inherently signals a mutating action, and the list of object types clarifies scope. However, it does not disclose whether the object is added to the active scene, whether it becomes selected, what defaults are applied, or what the result/return value is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence that communicates the core purpose immediately and then lists valid types. There is no redundant wording or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and complete schema coverage, the description is mostly adequate. Still, with no annotations and no output schema, it omits useful context such as how the new object is placed in the scene, default scale/location values, and whether the call returns an object reference or name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents name, type, scale, location, and rotation. The description mainly restates the type enum values, adding little semantic depth beyond the schema, such as units, coordinate conventions, or default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Create') and resource ('primitive object'), and enumerates the exact types supported. This distinguishes it from related tools like blender_curve_create or blender_mesh_from_data, especially through the type 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this when creating a primitive cube, sphere, cylinder, etc. However, it gives no explicit guidance about when to prefer an alternative creation tool, such as blender_curve_create, blender_mesh_from_data, or blender_collection_instance, despite many sibling tools being available.
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 the full behavioral disclosure burden. It clearly indicates a read-only enumeration of all objects in the scene, but it does not state the return format, whether hidden objects are included, or how the type_filter parameter affects results. This is adequate but 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and resource, and is appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool, this is nearly sufficient, but there is no output schema and the description does not specify what each listed object contains (e.g., name, ID, type). The optional type_filter is also only discoverable through the schema, not the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the only parameter (type_filter) completely with an enum and a description, so the baseline of 3 applies. The description adds no parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('objects in the scene'), and its scope is clear. It is distinguishable from siblings like blender_object_get and blender_scene_info, even though those alternatives are not named.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever you need to enumerate objects in the current scene. However, it provides no explicit guidance about when to prefer a sibling like blender_object_get for a single object or blender_collection_list for collections, so the routing burden is left to the agent.
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 behavioral disclosure burden. It clearly states the core effect: adding a soft body simulation to a mesh. However, it does not mention side effects like replacing existing physics settings, whether simulation only appears during playback, or any prerequisites beyond being a mesh object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, purposeful sentences. The primary action is front-loaded, and the second sentence adds relevant conceptual context without any filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for a simple 4-parameter tool with fully documented schema fields, but it lacks guidance on choosing soft body over closely related sibling physics tools and does not describe expected results or side effects. Given no annotations and no output schema, a bit more context would be warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter documentation already explains mass, friction, object_name, and goal_strength. The description adds no additional parameter-level meaning, but the schema already carries the burden sufficiently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Add soft body simulation to a mesh object.' The second sentence explains the defining physical behavior (deforming under forces while maintaining shape), which clearly distinguishes this tool from siblings like rigid body, cloth, or fluid simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The behavior description implies when a soft body would be appropriate, but it does not explicitly state when to prefer this tool over alternatives such as blender_physics_rigid_body_add, cloth, or fluid. No exclusions or contrast with sibling physics tools are provided, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does disclose the key behavioral trait—blend_factor semantics with explicit 0=keep current, 1=full saved pose—which is genuinely useful. However, it omits side effects (the armature's current pose is mutated), error behavior for nonexistent poses/armatures, and whether keyframes are auto-created or only poses applied. The blend explanation earns credit, but the mutation profile and failure modes are left undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words. The primary action is front-loaded in the first sentence, the blend behavior follows in the second, and the workflow use case closes it out. Every clause earns its place, and there is no fluff or repetition of schema details beyond the useful blend semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with 100% schema coverage and no output schema, the description covers the core operation and one use case adequately. However, with no annotations to convey the mutation/safety profile, the description could have noted prerequisites (pose must already exist in the pose library, armature must be valid) and clarified the result of applying a pose. These gaps leave the agent to infer failure conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all three parameters have descriptions), so the baseline of 3 applies. The description's blend_factor explanation (0=keep current, 1=full saved pose) essentially duplicates what the schema already states, adding no new parameter meaning. pose_name and armature_name receive no additional elaboration in the description beyond their schema entries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: "Apply a previously saved pose to an armature." The phrase "previously saved" cleanly distinguishes it from the inverse sibling blender_pose_library_save, and the pose/armature context separates it from other 'apply' tools (modifier_apply, geonode_apply). However, it never explicitly names an alternative, relying on inference rather than direct sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence, "Useful for creating animation keyframes from preset poses," gives the agent a concrete workflow context for when this tool is appropriate. It implies this is the apply-side of a save/apply pose pair, but it stops short of explicitly stating when not to use it or naming alternatives such as blender_pose_library_save or blender_keyframe_insert.
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 the transparency burden. It discloses the workflow steps (multi-angle render, vision analysis, convergence check) and the return values, but it remains silent on whether the object is modified, whether an active session is required, or whether the scene remains unchanged after the call. This is a meaningful gap for a refinement 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, key sub-steps, and expected return values with no filler. The colon-separated list is compact and easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the operation and result well enough for a simple call, but with no output schema and no annotations it does not describe orchestration prerequisites such as creating a refinement session first. It also leaves the convergence criteria and the exact meaning of 'issues' unspecified. For a multi-step AI-loop tool, this is functional but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all six parameters clearly. The description adds no additional meaning about how parameters interact, what defaults apply, or how previous_score and max_iterations influence convergence. Baseline 3 is appropriate when the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action: running one iteration of the AI refinement loop, and differentiates it from session-level or full-refine siblings by emphasizing 'one iteration' and the convergence check. It enumerates concrete steps the agent can expect, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is meant to be called within a refinement loop, but it does not explicitly say when to use it over alternatives such as blender_refine_create_session, blender_refine_get_session, or blender_ai_refine. No exclusions or transition conditions between loop control tools 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 are provided, so the description carries the behavioral burden. The Ctrl+Z analogy adds useful context, but the description does not disclose consequences such as irreversible state changes, failure when the undo stack is empty, or that it may undo actions beyond the AI's own previous tool calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and well-structured: the first sentence states the action and target, and the second sentence adds a familiar analogy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is largely complete: an agent can determine what the tool does and invoke it without additional input. Some minor behavioral details are missing, but the simplicity of the tool lowers the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the empty input schema fully covers parameter semantics. No parameter description is needed, so the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: undo the last operation in Blender, with the Ctrl+Z analogy reinforcing the meaning. It does not explicitly contrast with blender_redo or other siblings, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use this when the most recent Blender operation should be reverted. However, there is no explicit guidance about when not to use it, limitations such as repeated calls for multiple undos, or alternatives like blender_redo.
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 the full burden of explaining behavior. It does enumerate the repair operations and the pre-export context, which is useful. However, it does not disclose that the tool modifies the mesh in place, whether operations like interior-face removal are destructive, or what kind of result or confirmation the agent can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The first sentence front-loads the action and scope, and the second adds a clear use case, so every word contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mesh-repair tool with six fully documented parameters and one required object name, the description provides enough context to select and invoke it correctly. It covers what the tool does and when it is intended to be used. It does not mention in-place mutation or return behavior, but those gaps are relatively minor given the rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage and each parameter already includes a clear description and default value. The tool description adds no new parameter-level information, though its listed issues ('holes', 'inverted normals') do loosely map to the boolean parameters. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: fixing common mesh problems, and it enumerates specific issue types (non-manifold edges, holes, inverted normals, interior faces). It also adds the intended context of repairing AI-generated meshes before export. It does not explicitly differentiate itself from similar siblings like blender_ai_mesh_cleanup, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly gives a use case: 'Useful for repairing AI-generated meshes before export.' This gives clear context for when the tool is appropriate. However, it does not mention when not to use it or name any alternatives, so it lacks the explicit exclusions needed for a 5.
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 behavioral transparency burden. 'Get detailed statistics' strongly implies a read-only inspection operation and the output categories describe what is computed, but the description does not explicitly state that the mesh is not modified, how missing/invalid objects are handled, or that the object must be a mesh.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence that leads with the action and then provides a useful, specific enumeration of the statistics returned. Every part contributes meaning, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only statistics tool, the description is mostly complete: it names the key output categories and identifies the required input. However, there is no output schema and the description does not clarify units for bounding box dimensions, the exact meaning of 'and more', or behavior when the named object is not a mesh.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, object_name, is fully documented in the input schema ('Name of the mesh object to analyze') with 100% coverage. The description reinforces that the parameter refers to a mesh but adds no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get detailed statistics about a mesh') and enumerates concrete outputs: vertex/edge/face counts, bounding box dimensions, non-manifold edges, UV layers, material slots. This clearly distinguishes the tool from mesh-modification siblings and other measurement tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an agent needs mesh statistics, but it does not explicitly state when to prefer this tool over related tools like blender_measure_surface_area, blender_validate_mesh_quality, or blender_ai_mesh_cleanup. No exclusions or alternative selection guidance is 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 are provided, so the description carries the behavioral disclosure burden. It does state that the tool adds to the scene as a grease pencil annotation layer, implying a non-destructive additive operation. However, it does not disclose whether strokes are appended to existing layers, whether they can be cleared later, or any side effects beyond the layer creation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first front-loads the action and resource, the second provides relevant use cases. Every sentence earns its place, and the description is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple additive tool with four fully documented parameters and no output schema, the description is largely complete. It explains what the tool does and when to use it. The main gap is the lack of explicit guidance on choosing among nearby annotation-related siblings, which prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds little beyond '3D annotation strokes' and 'grease pencil annotation layer,' which slightly enrich the meaning of points and layer_name. Per the baseline rule, this warrants a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Add 3D annotation strokes to the scene as a grease pencil annotation layer.' This clearly conveys what the tool does and implicitly distinguishes it from annotation_text and annotation_dimension siblings by focusing on strokes. However, it does not explicitly distinguish itself from the similarly named grease_pencil_markup tool, so it stops short of perfect sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'marking up geometry, drawing guides, or highlighting areas of interest.' This tells an agent when this tool is appropriate. It does not mention alternatives or exclusions, such as using annotation_text for text labels or annotation_clear for removal, so it lacks explicit 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. 'Clear' conveys that annotation data is removed, and the description discloses the all-vs-specific behavior, but it does not mention side effects such as irreversibility, whether the layer itself is deleted, or what happens if the specified layer does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences communicate the core operation and the two modes with no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter tool with no output schema, the description is mostly complete. It covers the main two behaviors, though it omits minor details like error handling for non-existent layers and the exact nature of what is cleared.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains that omitting layer_name clears all annotation layers. The description adds no meaning beyond the schema, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('clear') and resource ('annotation layers'), and clearly distinguishes the operation from sibling tools like blender_annotation_add, blender_annotation_text, and blender_annotation_dimension. It also clarifies the two supported scopes: a named layer or all layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: clear annotation layers when annotations need to be removed. However, there is no explicit when-to-use vs. alternatives, no prerequisites, and no mention that this should not be used for deleting/creating annotation layers or for editing annotation content.
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 of disclosure. It openly states that the tool creates a bone hierarchy, optionally auto-weights the mesh, and configures for MSFS export. It does not detail potentially slow or destructive side effects of auto-weighting, but the main mutating behaviors are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core concept 'One-call auto-rig generator.' The long preset list is justified because each entry is paired with a short explanatory parenthetical, making the listing more informative without adding filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description covers the main invocation considerations: preset selection, optional auto-weighting, and MSFS compatibility. It does not mention the resulting armature's naming or how to reference the newly created object, but it provides enough for an agent to understand the operation and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3, and the description adds meaningful semantics by expanding every preset enum into understandable real-world analogs (BIPED humanoid, QUADRUPED four-legged, etc.). The optional auto-weight and MSFS configuration are also reflected in the description, though the booleans are mainly described via the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'One-call auto-rig generator' that 'creates a complete bone hierarchy' for a specific set of presets. It does not explicitly name sibling tools to distinguish from, but the phrase 'one-call' and the detailed preset list separate it from lower-level armature or rig-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through 'common use cases' and the enumerated preset types, which tells an agent this is for standard rigging scenarios. However, there is no explicit guidance on when not to use it or which alternatives to prefer, such as manual armature creation or rig validation tools.
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 adds the useful trait that the object is persistent and lives in the scene. However, it does not state what happens to existing objects, name-collision behavior, whether the new object becomes active, or what the tool returns. For a creation tool with zero annotation coverage, this is only partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the operative action and scope front-loaded. The second sentence earns its place by adding the persistence distinction; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with a well-documented 100%-coverage schema, the description is mostly sufficient: it identifies what is created, that it lives persistently in the scene, and that strokes are the input. The main gap is the absence of an explicit return/effect statement (no output schema exists), but the behavioral context plus schema make the tool safely callable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the meaning of name, color, strokes, points, and thickness is already fully documented. The description adds no parameter-level semantics beyond 'one or more strokes,' which only restates the schema's required property, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Create'), a precise resource ('grease pencil object'), and the key input requirement ('one or more strokes'). The second sentence's 'persistent 2D/3D drawing objects in the scene' differentiates it from ephemeral sibling annotation/markup tools, so an agent can distinguish it without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies when to use it—when a persistent grease pencil drawing is needed—but never explicitly names alternatives such as blender_annotation_add or blender_grease_pencil_markup or states when not to use them. The context is clear enough for a user who knows Blender conventions, but the description leaves the vs-alternative selection to inference.
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 of behavioral disclosure. It usefully explains how crease values affect subdivision results, which goes beyond a bare 'set crease values.' However, it does not mention prerequisites such as a subdivision modifier, side effects, or reversibility of the mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the main action, and uses the second sentence to add operational value. There is no redundant filler; the 'hard surface modeling tool' framing is brief and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core behavior and parameter meanings are adequately covered, and the schema documents all parameters. However, with no annotations and many similar mesh-editing siblings, the description could clarify selection precedence (edge_indices vs selected_only), the need for a subdivision modifier, and how crease differs from mark_sharp. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 practical meaning to the crease_value parameter by giving concrete visual outcomes ('keeps edges sharp through subdivision', 'softer feature lines'). The remaining parameters are already well documented in the schema, so no further compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Set edge crease values for subdivision surface control.' It clearly identifies the tool's domain (hard surface modeling) and operation. It doesn't explicitly differentiate from the closely related blender_mesh_mark_sharp sibling, but the purpose is still unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is for subdivision surface control and is framed as the hard surface modeling tool. It gives practical guidance on value selection ('crease=1.0 keeps edges sharp... crease=0.5 creates softer feature lines'). It does not mention exclusions or alternatives, but the intended scenario is clear enough.
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 the full burden of explaining behavior. It does convey the core effect of sharp-edge marking on normals, which is useful. However, it does not disclose side effects, selection precedence behavior, or whether the operation modifies data persistently, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the operation and the second provides the rationale/behavioral context. The key information 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mesh-editing tool, the description plus fully documented schema is largely sufficient. It explains the purpose, the parameter semantics are covered by the schema, and there is no output schema requiring return-value documentation. It could be more complete by noting possible prerequisites or side effects, but the core callable behavior is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters including edge_indices, selected_only, clear, and object_name. The description adds no additional parameter detail beyond referring generally to 'specific edges,' so it does not need to compensate and lands at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Mark or clear sharp edges.' It also explains the purpose of sharp edges ('override auto-smooth angle for precise normal control on specific edges'), which clearly distinguishes this tool from related mesh-editing siblings like mark_seam or crease.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by explaining that sharp edges override auto-smooth angle for precise normal control on specific edges. However, it never explicitly compares it to alternatives or states when not to use it, such as when needing seams or creases instead.
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 behavioral disclosure burden. It does explain the central side effect—proportional falloff affects neighboring vertices—and lists the supported transform modes. However, it omits operational details such as whether the object must be in edit mode, whether the operation is undoable, or how mesh data is committed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core action and use cases efficiently. The trailing 'via MCP' adds little value, but it is minor and does not detract significantly from the overall clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no annotations, and no output schema, the description adequately conveys when to use the tool but leaves gaps around prerequisites like edit mode, object type expectations, and failure behavior. It is minimum viable but not fully self-sufficient for correct invocation without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all six parameters with 100% description coverage, including enum options and defaults. The tool description adds context about proportional falloff behavior but does not add new parameter-level semantics beyond the schema, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states specific verbs and a specific resource: move, rotate, or scale vertices, with proportional falloff affecting neighbors. This clearly distinguishes the tool from object-level transforms like blender_object_transform and from other mesh editing operations. The intent is immediately recognizable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description supplies clear contexts for use: organic shape refinement, smooth deformations, and sculpt-like adjustments. It does not explicitly state when not to use it or name alternatives such as blender_object_transform, but the intended scenarios are specific enough to guide selection.
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 transparency burden. It clearly states that it mutates objects by adding physics and that a ground object becomes a PASSIVE collider, but it does not disclose whether existing rigid-body settings are replaced, whether the operation is idempotent, or what the return/result is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the primary action in the first sentence and the optional variation in the second. No filler or duplication of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batched mutation with a fully self-documenting schema, the description supplies the core intent and the key optional behavior. It lacks only explicit guidance on conflicts with existing physics settings or how this relates to simulation tools, which are minor given the schema richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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's mention of a PASSIVE ground/floor mirrors what the ground_object parameter already documents; it adds no substantive parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Add rigid body physics') and explicitly scopes the operation to 'multiple objects at once,' which differentiates it from the sibling blender_physics_rigid_body_add. The optional ground/floor as PASSIVE collider further clarifies the tool's distinctive capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The batch wording implies this tool is for adding physics to several objects at once, but it never explicitly names the singular sibling alternative or states when not to use it. The ground-object sentence gives useful contextual guidance for the optional parameter, but no explicit when/when-not rules.
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 carry the behavioral burden. It does disclose the key behavior—capturing the current viewport to an image—but it does not mention output format, resolution behavior, or whether the file is overwritten. For a non-destructive capture operation, this is minimally 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, unambiguous sentence with no redundant wording. It front-loads the core action and output without trailing filler or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, one required parameter, and 100% parameter coverage, the description is mostly complete for an agent to invoke it correctly. Some details like file format or return value are absent, but the essential information needed to call the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the output_path parameter is documented as 'Output file path'. The tool description adds no additional meaning beyond the parameter name and schema description, which matches the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Capture', identifies the exact resource ('the current viewport'), and states the output form ('as an image'). This clearly distinguishes it from tools like blender_render_image or blender_render_animation, which imply full renders rather than a viewport screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'current viewport' implies when to use this tool: when a quick capture of the visible viewport is needed. However, it does not explicitly contrast this with blender_render_image or mention when not to use it, so the usage context is implied rather than 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?
With no annotations, the description carries the behavioral disclosure burden. It adds one useful side-effect detail—creating parent directories if needed—but does not mention overwriting behavior, whether the current file path changes after saving, or any failure conditions. The `copy` parameter in the schema partially covers path behavior, but the description itself is thin on 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every clause earns its place: the action is stated first, and the parent-directory side effect is included as a useful extra detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three flat, fully documented parameters, the description plus schema is mostly sufficient. It covers the core purpose and one valuable side effect. The main gaps are lack of explicit overwrite behavior and no detail about what the tool returns, but these are relatively minor given the schema coverage and absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters already documented meaningfully in the input schema. The tool description adds no additional parameter-level information, so it meets the baseline but does not go beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation: saving the current Blender file to a new path. It is specific about the action and resource and is naturally distinguishable from the sibling `blender_save`, though it does not explicitly explain the relationship or the current-file path update 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to a new path' provides a clear contextual trigger for when to use this tool, and the sibling `blender_save` is the obvious alternative. However, it does not explicitly state when not to use it or name the alternative directly, so the guidance is clear but not fully exhaustive.
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 the burden of behavioral disclosure. It tells the agent the output type (difference score and overlay image) and the general behavior (render silhouette and compare), which is helpful. However, it does not disclose what file formats the difference score/overlay come in, whether the overlay is saved to disk or returned as base64, whether the object must be visible/selected, or whether this writes any files to the filesystem.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, followed by the output types and the purpose. Every element earns its place; no filler or redundant restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter tool with a fully documented schema, the description names the output and purpose, which covers most of what an agent needs to invoke it. The main gap is the return format of the overlay image and where the difference score is delivered, but the purpose and output types are sufficiently clear for initial selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters clearly. The description names the key components (object, reference image, silhouette comparison) but does not add significant meaning beyond the schema, such as how camera_angle affects the silhouette comparison or what resolution implies for the difference score. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Render object silhouette') and resource ('compare against a reference image'), with a clear output ('difference score and overlay image') and purpose ('proportion verification'). Among the large sibling list, there is no other tool doing silhouette comparison; it stands out from render-only tools (blender_render_image, blender_render_multi_angle) and measurement tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for proportion verification, but it does not explicitly state when to use it instead of alternatives like blender_render_image, blender_render_multi_angle, blender_measure, or blender_calibrate_from_reference. No when-not-to-use conditions or alternative tool names are given. The purpose sentence gives adequate context for an agent to infer the right time to call it.
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 carry the full burden. It does describe the output format (per-axis pass/fail with deviations), but it does not disclose whether the operation is read-only or if there are any side effects. It also does not mention behavior when the object is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff, front-loading the main action and result. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for an agent to understand the tool's purpose and output, but it lacks details on edge cases like missing objects or error handling. Since there is no output schema, the description gives a high-level return description but not a precise format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the description adds little beyond what is already in the schema. It mentions 'configurable tolerance' and 'per-axis' which are also in the schema, so it doesn't add substantial new meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks an object's bounding-box dimensions against expected values with tolerance, and reports per-axis pass/fail with deviations. It is specific and distinguishes from siblings like blender_measure which likely measure actual dimensions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for validation scenarios but does not explicitly differentiate from alternatives like blender_measure or mention when not to use it. It provides 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose key traits: blocking synchronous behavior, combined generate+poll+optional import, and return on completion. But it omits the timeout behavior implied by max_wait (what happens when the limit is exceeded?) and the default side-effect that auto_import=true modifies the Blender scene by default. These are material gaps for a blocking 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: purpose and sync mode, combined workflow, and return behavior. Front-loaded with the core function and zero filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The workflow is well covered for a 7-parameter wrapper and the schema is complete, but with no output schema the vague 'Returns the final model when done' leaves the return structure unspecified (file path? object name? status object?). The timeout/error behavior gap also remains. Adequate but incomplete for an agent that must handle failure cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline of 3 applies; the schema already documents every parameter with a description and 3 enums. The description adds little per-parameter meaning — only 'optional import' maps to auto_import — so there is nothing it needs to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Generate a 3D model') and immediately adds the defining trait — '(synchronous)' — that separates it from the async blender_ai_generate_model sibling. The phrase 'Combines generate + poll + optional import in one call' explicitly defines its scope relative to the generate/poll workflow tools, so an agent can distinguish it without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear usage context: this is the one-call blocking alternative to a generate-then-poll workflow, with optional import. However, it never explicitly names the alternatives (blender_ai_generate_model, blender_ai_model_status) nor states when to prefer the async path (e.g., long generations, parallel work). Clear context, but no explicit 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 carries the behavioral transparency burden. It discloses the core operation, supported methods, vertex-group targeting, and UV preservation, but it does not state whether the mesh is modified in place permanently, whether an undo is available, or what side effects occur on the original object. This leaves important behavioral uncertainty for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no filler. The main purpose is front-loaded, followed by method support and key options, and every sentence contributes useful selection or invocation information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and several parameter-level behaviors, and the schema fully documents all parameters. However, with no output schema and no annotations, it does not explain the result of the operation, whether the object is changed destructively, or how this decimation relates to Blender's modifier system. For a mutation tool, this leaves moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful semantic context: 'Reduce polygon count' clarifies the ratio parameter's intent, 'target specific vertex groups' maps to vertex_group, and 'optionally preserve UVs' reinforces preserve_uvs. This goes beyond the schema's per-field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Reduce polygon count of a mesh while preserving shape.' It also names the supported methods and advanced targeting features, making it clear this is the polygon-reduction tool and distinguishing it from mesh cleanup, remeshing, or LOD-specific 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reducing polygon count while retaining shape, but it does not explicitly state when to prefer this tool over related alternatives like blender_ai_mesh_optimize or blender_msfs_decimate_for_lod. No exclusions or alternative routing is provided, so the agent must infer usage from context.
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 disclosure burden and does a good job: it reveals the render-evaluate-return sequence and implies the tool does not itself apply suggestions since it says to apply them between calls. It could still be clearer about side effects and external dependencies, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler, and the most important scoping ('one iteration') is front-loaded. The loop instruction earns its place by explaining the intended calling pattern.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the iteration workflow but omits return-shape details (no output schema) and does not clarify how it relates to blender_refine_iteration or the session-management tools. An agent may still be unsure which refinement tool to select.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds no parameter-specific meaning beyond the loop/convergence context already reflected in max_iterations and quality_threshold.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a concrete verb and resources: 'render object, evaluate with vision model, return scores and suggestions,' so an agent can infer the operation. It does not explicitly distinguish this from nearly identical siblings like blender_refine_iteration or blender_ai_evaluate, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: 'Call repeatedly in a loop, applying suggestions between calls, until converged.' This tells the agent the intended workflow, but it does not say when to prefer this tool over the session-based or evaluation siblings.
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 behavioral disclosure burden. 'Jump to a specific frame in the timeline' clearly conveys that this is a non-destructive navigation action affecting the current frame. It does not mention whether playback is stopped or whether the change can be undone, but for such a simple operation the core behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. The core action is front-loaded and every word contributes to meaning, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter seek operation with no output schema, the description plus schema fully cover what an agent needs to invoke the tool correctly. Nothing operationally important is missing, and the sibling ambiguity is minimal given the clear 'jump to frame' semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter ('Frame number to jump to') with 100% coverage. The description adds no extra semantic nuance beyond the schema, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Jump') and a specific resource ('a specific frame in the timeline'). It also implicitly distinguishes itself from sibling tools like blender_animation_play and blender_scene_set_frame_range, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives such as setting the frame range or playing the animation. There is no mention of context, prerequisites, or exclusions, so the agent must infer usage from the name alone.
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 exist, so the description carries the burden. It transparently explains how the curvature is calculated and how values are mapped to dark/bright areas, which adds real behavioral context. However, it does not disclose potential prerequisites such as UV mapping or side effects like overwriting an existing file at output_path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences deliver purpose, method, and use cases with no filler. The main action is front-loaded, followed by necessary technical detail and application guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bake operation with no output schema or annotations, the description covers the core purpose and output mapping well. It omits practical prerequisites such as whether the target object needs UVs or a material setup, and it does not specify output format behavior tied to output_path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured schema already documents all four parameters. The description adds algorithm-level context that relates to cavity_type (concave/convex) but does not enrich the meaning of object_name, output_path, or resolution beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Bake a curvature map from mesh geometry.' It provides the algorithm (dot product of vertex normals vs averaged neighbor normals) and the concave/convex output semantics, which clearly differentiates this from the many sibling bake and material tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states clear contexts for use: 'edge wear, dirt accumulation, and procedural texturing masks.' It does not explicitly contrast with sibling bake tools like blender_bake_highpoly_to_lowpoly or blender_bake_id_map, but the use cases make the intended scenario evident.
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 carry the behavioral burden, and it does disclose the core effect: creating a material and generating a shader node tree. However, it does not state whether the material is assigned to an object, whether an existing material with same name is overwritten, or what the caller receives as a result. This is adequate but leaves important side effects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and front-loaded: it states the operation, the one-call advantage, the node-tree behavior, and then the preset names. The preset enumeration is long but operationally necessary, and there is no filler or repetition beyond that.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters are documented by the schema and the core behavior is clear, so an agent can invoke it. But without annotations or an output schema, the description leaves important context unspecified: assignment behavior, name-collision behavior, and return value. For a tool in a large material-related sibling group, these gaps make the definition only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains name, preset, color, scale, and wear_amount. The description adds no new parameter-level semantics beyond repeating the preset list, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a precise verb+resource: create a complex procedural material from a named preset in one call. It also says the tool builds a full shader node tree, which clearly distinguishes it from material_create, set_principled, node_add, and other sibling material tools. The preset list reinforces what the tool produces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with one call' and 'builds a full shader node tree' gives an agent a clear context: use this when you want a ready-made procedural material without assembling nodes manually. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5, but the usage context is otherwise clear.
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 behavioral disclosure burden. It does disclose optional filtering, threshold-based flagging, and degree units, but it never states whether the operation returns a list, mutates the mesh, highlights edges, or produces a report. For a non-annotated tool this is a partial but not complete disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads the core purpose, then adds optional behavior and unit information. Every phrase contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters and no output schema, so the description should clarify what the agent receives after invoking the tool. It explains degree units and flagging, but not the return format, how flagged edges are represented, or behavior when no edges qualify. This is a notable gap given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds context about the measurement type and unit, but it does not add meaningful semantics beyond what the schema already provides for object_name, edge_indices, threshold_max, or threshold_min.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Measure'), a specific resource ('dihedral angles at mesh edges'), and clarifies the angle type as face-to-face. This cleanly distinguishes it from sibling measurement tools like blender_measure_surface_area and blender_measure_volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is appropriate: when dihedral angles at mesh edges are needed. It does not explicitly name alternatives or when-not-to-use conditions, but the resource scope is specific enough to route an agent correctly among the measure-related siblings.
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 behavioral burden. It does disclose the edge-targeting behavior and the auto-selection of sharp edges, but it does not state whether the operation modifies the mesh destructively in place, whether object selection or edit mode is required, or what side effects apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose and followed by the key edge-targeting behavior. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for selecting the tool and understanding its basic behavior, but with no annotations and no output schema, it omits important operational context such as whether the bevel is applied destructively to the mesh, what happens when no edge_indices are provided, and how sharp edges are determined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no parameter-level detail beyond what the schema provides, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Bevel'), a specific resource ('edges'), and the intended visual outcome ('smooth transitions and rounded corners'). It also mentions the two targeting modes, which clearly distinguishes it from the many other mesh-editing siblings in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when wanting smooth transitions or rounded corners. It also explains the two usage modes (targeting specific edges vs. auto-selecting sharp edges), though it does not explicitly name alternatives or exclusions.
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 behavioral burden and does disclose the key side effects: it can clear geometry on either side and fill the cut plane. It also clarifies the geometric behavior of an infinite cutting plane. It does not state whether the original mesh is modified in place or what the default result is when clear/fill flags are false, but the core mutation semantics are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first sentence states the mechanism immediately, and the second summarizes optional behavior and provides a concrete use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation, the geometry, and the optional behaviors, which is adequate for selecting the tool. However, with no output schema and no annotations, it doesn't describe the return value, whether the mesh is destructively modified, or the default result when no clear/fill options are set. These are meaningful gaps for a mutation tool, though not severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description reinforces the meaning of plane_point, plane_normal, clear_inner/clear_outer, and fill, but adds no new constraints, formats, or edge-case details beyond the schema, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact operation ('Cut mesh'), the geometric method ('infinite plane defined by a point and normal'), and optional outcomes (clear sides, fill cut). This is a specific verb-plus-resource statement that clearly distinguishes bisect from sibling mesh operations like bevel, extrude, or loop_cut, even without naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Perfect for splitting vehicles into sections' provides a concrete use case, so an agent can infer this is for slicing a mesh along a plane. However, there are no explicit when-to-use/when-not-to-use conditions or named alternatives such as mesh_split or knife_project, so the guidance is implied rather than 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?
With no annotations, the description carries the full burden of behavioral disclosure. It implies an in-place topology modification by stating it creates connecting faces, but it does not disclose prerequisites such as whether both loops must belong to the same object, matching loop sizes, or how invalid selections behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the core action front-loaded, followed by three concise, relevant use cases. Every phrase earns its place and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose well but leaves out important operational context for an unannotated mesh-modification tool: expected return value, prerequisites for valid edge loops, and failure behavior. Since there is no output schema or annotations, this gap is noticeable but not fatal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents every parameter, including twist, segments, profile_factor, and the edge loop arrays. The tool description adds no parameter-level meaning beyond what the schema provides, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Bridge two edge loops to create connecting faces,' which clearly states the operation and result. It also gives concrete use cases like connecting body panels and creating tubes, which help distinguish it from similar mesh tools such as fill or merge.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual use cases: connect body panels, create tubes between openings, join separate mesh islands. It does not explicitly mention when not to use it or name alternatives, but the examples strongly signal appropriate scenarios.
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 present, so the description carries the full burden. It discloses the core mutating behavior (removing elements) and the key merge-to-fill-gap effect, which is meaningful. However, it omits potential side effects such as UV/topology changes, invalid-index handling, or whether the object must be in edit mode, leaving gaps for a destructive mesh 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action and then the distinguishing contrast. It is efficient, scannable, and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mutation tool with no output schema and no annotations, the description covers the core operation and the delete-vs-dissolve distinction. It omits practical context like prerequisites (edit mode, object type), behavior on invalid indices, and relationships to sibling tools like merge or fill, so it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for all four parameters including the mode enum, indices, object_name, and use_face_split. The description adds no parameter-specific meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Remove') with a clear resource ('vertices, edges, or faces') and adds the distinctive behavioral nuance 'preserving surrounding geometry.' The contrast 'Unlike delete, dissolve merges the surrounding geometry to fill the gap' clearly separates it from deletion and communicates its unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with delete, explaining that dissolve merges surrounding geometry to fill the gap, which gives an agent actionable guidance on when to prefer this tool over deletion. However, it does not mention alternatives like merge or fill, nor provide explicit exclusions, so it is not a complete routing guide.
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 behavioral disclosure burden. It conveys that the operation is additive and localized, but it does not state whether the mesh is modified in place, what prerequisites exist (e.g., a valid edge index), or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action and key differentiator are front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no annotations and no output schema, the description is somewhat thin. It explains the purpose and differentiates from whole-mesh subdivision, but omits practical details like how to identify a valid edge_index, whether the operation requires a specific object mode, and what the expected result or return value is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents every parameter. The description adds only thematic context ('specific areas') and does not deepen understanding of edge_index, cuts, or smoothness beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb and resource: adding edge loops to a mesh. It also explains the intended use ('topology control') and contrasts with subdividing the whole mesh, which helps distinguish it from sibling tools like blender_mesh_subdivide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this for targeted topology resolution in specific areas rather than whole-mesh subdivision. It implies the alternative but does not explicitly name it or state when not to use the tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description has to carry behavioral disclosure on its own. It does disclose advanced capabilities (grow/shrink, linked selection) and the return contract ('Returns selected indices'), but it never states that the tool modifies the object's active selection state in Blender, which is a meaningful behavioral trait for a selection tool with an action parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences front-load the core purpose, enumerate criteria and capabilities, and close with the return behavior. No filler or repetition, and every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 16-parameter tool with no annotations and no output schema, the description is adequate but not complete: it explains the return value and highlights the main filter families, but does not clarify how multiple criteria combine (AND vs OR), how action interacts with filter criteria, or what happens when no criteria are supplied. The schema fills some gaps but the high complexity warrants more operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description adds useful grouping of categories (by index, position, normal, material, angle, area) and links grow/shrink/linked to parameters, but it does not add substantial meaning beyond the schema for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Multi-criteria mesh selection engine' and enumerates concrete selection criteria (index, position range, normal direction, material, edge angle, face area) and element modes (vertices, edges, faces). This makes its general-purpose role clear and distinguishes it from specialized siblings like blender_mesh_select_shortest_path or blender_mesh_select_edge_loops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'multi-criteria' framing plus the enumerated criteria give an agent clear context for when to use this tool: when selection depends on parametric filters rather than topology/shortest-path/linked-flat heuristics. It does not explicitly name alternatives or state when not to use them, so it stops short of full exclusion guidance.
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 of behavioral disclosure. It conveys the core mutating behavior (vertices get repositioned onto another surface) but does not clarify whether the deformation is a permanent direct edit or a modifier-based operation, whether it is reversible, or what happens with invalid targets. For a geometry-mutating tool with zero annotation coverage, this is a notable but non-fatal gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that leads with the core verb phrase, followed by two compact illustrative examples. Every word earns its place; there is no fluff, repetition, or irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (5 params, 1 enum, 2 required) and the schema covers all parameters, so the essential calling contract is documented. However, with no annotations and no output schema, the description should disclose side effects, prerequisites (e.g., target must be a mesh object), and whether the edit is destructive. The partial use-case guidance does not fully close that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 reinforces the meaning of object_name and target_object ('another object's surface') but adds no meaning for mode, offset, or vertex_indices beyond what the schema already provides. The description does not compensate beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Snap vertices to another object's surface.' This clearly identifies the operation and the involved objects (vertices being snapped, a target surface). The concrete examples ('conform details to body panels, project geometry onto curved surfaces') further clarify intent and distinguish it from sibling mesh editing tools like extrude, bevel, or inset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The examples 'conform details to body panels, project geometry onto curved surfaces' provide clear context for when this tool is appropriate. However, it does not explicitly name alternatives or state when not to use it (e.g., it doesn't mention that permanent geometry edits differ from adding a non-destructive modifier via blender_modifier_add).
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 behavioral disclosure burden. It does add useful behavior: it 'creates hard boundaries' and works 'by duplicating shared vertices,' implying an in-place mesh mutation. However, it doesn't mention potential side effects, whether the operation is destructive, or if specific mesh selection states are required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the operation, scope, and key behavioral outcome. Every phrase earns its place, and there is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the operation and mechanism well enough for a simple mesh edit, but with no annotations and no output schema, it leaves out some context such as mutability caveats, error behavior, or how the result is reflected. Still, for a 3-parameter tool with full schema coverage, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 three parameters. The description's mention of 'edges or faces' aligns with the mode enum but adds no new meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('split') and resource ('edges or faces'), and explicitly clarifies that it operates 'within the mesh' and does NOT separate into a new object. This clearly distinguishes it from sibling tools like blender_object_separate and blender_mesh_separate_selected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without separating into a new object' provides clear context and rules out the main alternative use case. It doesn't explicitly name alternatives or state when not to use other mesh editing tools, but it does set an exclusion boundary that helps an agent select it correctly.
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 the full burden. It discloses that a new mesh is created, faces above the mask threshold are used, and thickness can be added via solidify. However, it does not state whether the original sculpt is modified, what happens to the mask afterward, or how the resulting object is named or selected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences: what the tool does, how it does it, and when it is useful. There is no filler, and the most important information is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description and schema together cover the main inputs and mechanism, but with no output schema and no annotations, the agent is left unsure about the return value or how to reference the newly created object afterward. It also omits whether the original object is preserved, which matters for sculpting workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 context by linking thickness to solidification and smooth_iterations to boundary smoothing, but these are already reflected in the schema parameter descriptions. No meaningful semantic detail beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Extract the masked region of a sculpt as a separate mesh object.' It clearly states the result (a new mesh object) and differentiates from sibling sculpt and mesh tools by focusing on mask-based extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this when you need to extract a sculpted masked region into a standalone mesh, and it gives practical use cases like armor plates and panel lines. However, it does not explicitly mention alternatives or when not to use this tool.
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 the behavioral disclosure burden. It adds useful traits—filters affect the whole mesh uniformly and work reliably over MCP—but it does not disclose side effects, permanence, undo behavior, or failure conditions for a mutation-like operation. The core behavior is stated, but operational risks are left implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, purposeful sentences with no fluff. The main action is front-loaded, the differentiating trait comes second, and concrete use cases round it out efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for selecting and invoking the tool, especially with a fully documented schema. However, with no output schema and no annotations, it does not cover return behavior, required object state beyond the schema hint, or side effects, leaving some operational ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all four parameters with descriptions and an enum. The description adds general context for what filter types do (smoothing, sharpening, surface noise, inflating, relaxing) but does not add parameter-specific meaning beyond the schema. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource—'Apply global mesh filters to a sculpt-mode object'—and immediately clarifies its defining difference from brush strokes by noting filters affect the entire mesh uniformly. This makes it easy to distinguish from the many nearby sculpt and mesh tools in 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear practical guidance: use this when a global, uniform mesh effect is needed rather than localized brush strokes, and it notes that this approach works reliably over MCP. It could be stronger by naming a specific alternative tool, but the 'unlike brush strokes' contrast provides actionable selection guidance.
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 usefully reveals the voxel round-trip mechanism and flags the resource cost of small voxel_size ('more polygons'). But it omits that a remesh rebuilds topology from scratch, typically destroying UV maps, shape keys, and vertex groups, and never states whether the object is modified in place.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, mechanism, use cases, and the key parameter tradeoff. The core verb-object statement is front-loaded, and there is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what, why, when, and the main parameter knob, which is adequate for a simple tool. However, for a destructive mesh operation with zero annotations, it should disclose side effects (loss of UVs/attributes), in-place vs. new-object behavior, and how it differs from blender_ai_mesh_remesh. These gaps are material for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 marginal value for voxel_size by restating the detail tradeoff and adding the polygon-count consequence, but smooth and fix_poles receive no context beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb-resource pair ('Apply voxel remesh to create a uniform topology'), explains the mechanism ('Converts the mesh to a voxel representation and back'), and the outcome ('evenly-spaced quads'). The voxel method is clearly named, which distinguishes it from the similarly-purposed sibling blender_ai_mesh_remesh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names three appropriate contexts: cleaning up boolean results, imported meshes, and preparing for sculpting. However, it never names alternatives or states when not to use it, particularly versus the AI-based remesh sibling, so it falls short of full exclusion guidance.
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 behavioral burden. It does disclose the core behavior and projection methods, but it does not mention side effects such as whether an existing UV layer is replaced, whether the mesh must be in a particular mode, or what the operation returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that names the operation, methods, and key controls without any filler, redundant phrasing, or unnecessary detail. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with full schema coverage and no output schema, the description plus schema is largely sufficient to select and invoke the tool. It lacks explicit return-value or caveat information, but the core effect and parameter semantics are adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 mirrors several key parameters (angle limit, island margin, area weighting, aspect correction) but adds no meaning beyond what the input schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Generate UV maps') against a specific resource ('a mesh'), and names the exact projection methods (SMART or LIGHTMAP) and tunable controls. This is clearly distinguishable from any sibling UV-related or mesh-modification tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is explicit: use this when you need to generate or update UV maps on a mesh via SMART or LIGHTMAP projection. No alternative UV-unwrap sibling exists in the tool list, so not naming alternatives is acceptable; the context is clear even without explicit 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of explaining behavior. It states that the tool creates an armature from bone definitions and describes the fields involved, which is a minimally adequate disclosure. However, it does not mention whether the armature is added to the current scene, how connected bones behave beyond what the schema says, or any coordinate-space assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. It front-loads the primary action and immediately gives the necessary context for how bones are specified. Every sentence contributes useful selection and usage information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, one required, and a fully documented schema, so the description does not need to repeat parameter details. It conveys the core purpose and the main use case. It could add guidance on scene placement or return behavior, but given the schema coverage and simple create operation, the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description helpfully summarizes the key bone fields (head/tail, parent, connection, roll) but does not add substantial meaning beyond the schema. This matches the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create an armature from a list of bone definitions.' It clearly distinguishes this tool from generic object creation tools by focusing on armature/bone construction. The mention of precise skeleton construction from known bone positions further clarifies its unique role among the sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this for precise skeleton construction from known bone positions,' which gives a clear context for when this tool is appropriate. It does not explicitly name alternatives or list when not to use it, but the use case is specific enough that an agent can select it confidently.
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 present, the description carries the behavioral disclosure burden. It usefully states that Geometry input/output sockets are automatically added and that the tool returns the group name and socket layout, which gives the agent a clear picture of the side effects and result.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each adding distinct value: what is created, the automatic socket behavior, and the return value. No filler or redundant restatement of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description adequately covers the essential behavior and return value. It does not mention name-collision behavior or how to subsequently use the created group, but the information needed to call the tool and interpret its result is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all parameters with 100% coverage, so baseline is 3. The description adds meaning by clarifying that the provided inputs and outputs are 'extra' beyond the automatically added Geometry sockets, which helps the agent correctly populate the optional arrays.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('Geometry Nodes node group'), and adds that inputs/outputs are typed. It clearly distinguishes this from the nearby material_node_group_create tool by naming the resource explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, such as material_node_group_create or the other geonode tools. The agent must infer usage from the tool name and sibling context rather than from explicit direction.
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 behavioral burden. It clearly signals a read-only query through 'Return' and 'inspect', and it details exactly what the operation yields: nodes with name/type/location/connections and links. It does not explicitly state that no material state is modified, but for a query tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the core purpose and output format, the second enumerates the exact contents. The description is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description compensates well by enumerating the returned JSON contents (nodes and links with their fields), which is enough for an agent to know what to expect. It does not mention behavior when the material name is invalid or missing, but that is a minor gap for a read-only inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, material_name, is already fully described in the schema as 'Name of the material to inspect', and the description adds no additional format, naming, or qualification details. With 100% schema coverage, the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Return'), resource ('full shader node graph of a material'), and output format ('structured JSON'), while listing exactly what is included. This clearly distinguishes it from sibling material tools like blender_material_list, blender_material_node_add, and blender_material_node_connect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Return ... graph' phrasing implies usage for inspecting an existing material's node structure, but the description never explicitly says when to choose this over material_list or node-editing tools, and it gives no exclusions or alternative routing.
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 accurately states the primary effect (creates a reusable node group) and its future usability. However, it does not disclose behavior around naming conflicts, whether this modifies the current material, or what the tool returns after creation, which are relevant for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The primary action and purpose are front-loaded, and the follow-up sentence provides the key future-use context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema already documents parameters and the description explains the reusable nature and eventual instancing, the tool is largely complete. A minor gap is the lack of explicit statement about where the group is stored or whether it becomes active in the current node tree, but this is not severely needed for the primary create action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already documented including socket types and default values. The description adds no additional parameter-level meaning beyond restating that inputs and outputs can be defined, so the baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') with a clear resource ('reusable shader node group') and states the group's defined inputs/outputs. It also distinguishes this tool from simpler node operations by noting the group can later be instanced via a ShaderNodeGroup node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the intended use case: creating a reusable group for later instantiation in any material. It does not explicitly list exclusions or alternatives, but the context is unambiguous enough for an agent to select this over sibling material_node_add or material_procedural_preset tools.
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 present, so the description carries the behavioral disclosure burden. It conveys a non-destructive measurement operation, reports units, and notes local/world-space support, but it does not describe behavior for invalid objects, non-mesh objects, or missing material slots. Adequate but with gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no filler. The main purpose is front-loaded, followed by output units and supported modes. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple measurement tool, the description covers the core behavior, units, and optional modes. Since there is no output schema, a bit more detail about the exact return structure, especially the per-material breakdown shape, would improve completeness, but the current description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description's 'optional per-material breakdown' and 'local or world-space calculation' align with per_material and world_space but do not add meaningful new parameter-level detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Calculate total surface area of a mesh object.' It clearly distinguishes this tool from volume, clearance, and edge-angle measurement siblings, and adds useful scoping details like units and coordinate space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this is the tool for surface-area measurement, and mentions the optional modes and units. It does not explicitly name alternatives or provide exclusionary guidance, but for a straightforward measurement tool the intended use is well implied.
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 burden of behavior disclosure. It does explain the pairing criteria—angle and UV matching—and implies an in-place topology modification. However, it doesn't mention side effects, reversibility, or what happens when no valid quad pairs are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence that front-loads the operation and outcome before giving the pairing criteria. No wasted words or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a focused mesh operation with a fully documented input schema, the description is largely complete: it explains what the tool does and the algorithm it uses. It stops short of noting in-place mutation or operation limitations, but no major information needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds minimal semantic value by referencing angle and UV matching, which loosely maps to angle_limit and compare_uvs, but does not meaningfully supplement the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource—'Convert triangles to quads'—and states the intended outcome: cleaner quad topology. This clearly differentiates the tool from the many sibling mesh operations like dissolve, merge, or remesh.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear use context: cleaning up triangulated meshes to achieve quad topology. It doesn't explicitly name alternatives or exclusion cases, but the purpose is specific enough that an agent can infer when this tool applies.
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 behavioral disclosure burden. It accurately indicates a read-only list operation but does not mention return format, whether the list is static or queried live, or any prerequisites. This is adequate for a trivial getter but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One succinct sentence front-loads the action and resource, with parenthetical examples. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument listing tool the description is mostly complete, but it could connect the result to downstream siblings (get_template_info, download_template) and clarify the output shape since there is no output schema. Minor gap only.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4; there is nothing for the description to add beyond the empty schema. The examples in the description give some context about what the returned list will contain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get list of supported aircraft templates') and gives concrete examples ('FBW A32NX, Fenix, PMDG, iniBuilds'). This clearly distinguishes it from sibling template tools like get_template_info and download_template, which operate on a single template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use (enumerate available aircraft templates before selecting one) is implied but not stated explicitly. The description does not name the related livery template tools or explain when this list should be fetched instead of get_template_info or download_template.
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 must carry the full burden of behavioral disclosure. It does communicate that transforms are baked into mesh data, implying permanent modification, but it does not explicitly warn about irreversibility, potential side effects on children/constraints, or whether only mesh objects are supported. This is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the operation, specifies the target resource, and describes the result, so every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and no output schema, the description captures the core effect and scope clearly. The schema covers parameter semantics, and the description explains the operation's purpose and result. Minor gaps remain around irreversibility and explicit exclusions, but the tool can be invoked correctly based on the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters at 100% coverage, giving a baseline of 3. The description adds value by explaining that the location/rotation/scale booleans correspond to those transforms being reset to identity after baking, which clarifies their effect beyond the schema's simple 'Apply ...' labels.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply (bake)') and names the resource ('object transforms') with a clear outcome ('location/rotation/scale reset to identity'). This distinguishes it from related tools like blender_object_transform, which changes transforms rather than baking them into mesh data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool—when transforms should be baked into mesh data so they reset to identity—but it does not explicitly state when not to use it or name alternatives such as blender_object_transform or blender_object_set_origin. The usage context is inferred rather than explicit.
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 behavioral burden. It states the core effect (participates in physics and is either active or passive), which is useful, but it does not disclose side effects, prerequisites, or what happens if the object already has a rigid body.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, with zero filler. The second sentence earns its place by clarifying the key behavioral distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-object setup tool with fully documented parameters, the purpose and behavioral mode are adequately covered. It could be more complete by pointing to the batch sibling or noting prerequisites, but nothing essential is missing for a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 reinforces the body_type semantics ('active'/'passive'), but that information is already in the schema's parameter descriptions, so it adds little beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Add a rigid body physics simulation to an object.' It also explains the active/passive distinction, which makes it easy to distinguish from cloth/soft/fluid simulation tools and from the batch sibling by emphasizing a single object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when an object should participate in rigid body physics as a dynamic or static body. It does not explicitly name alternatives like blender_physics_rigid_body_batch or state exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It states the core behavior and the keyboard equivalent, which is transparent for a simple no-parameter action, but it does not mention side effects, failure behavior when the redo stack is empty, or whether any state is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one short sentence that wastes no words. The core action is stated first, and the shortcut equivalence adds a helpful but non-essential detail at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, standard redo operation, the description is nearly complete: it identifies the action and the equivalent shortcut. It mostly lacks an explicit note about the absence of an undo history producing no effect or an error, but given the tool's simplicity, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema fully covers the input surface and the description needs to add nothing about parameters. The baseline of 4 applies because no parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Redo') and resource ('the last undone operation in Blender'), and is immediately understandable. It also implicitly differentiates itself from the sibling blender_undo by stating it performs the opposite action, and the Ctrl+Shift+Z shortcut reinforces the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool should be used after an undo has occurred, but it does not explicitly state when to use it versus blender_undo or what happens when there is nothing to redo. The shortcut equivalence provides useful context, but the guidance is mostly inferred rather than 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It communicates a read-only listing operation and specifies what will be returned, but it does not explicitly confirm the absence of side effects, ordering, or pagination behavior. This is adequate for a simple list operation but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler. It front-loads the action and scope, immediately states what is listed, and specifies the included fields. For a zero-parameter tool, this is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with no output schema, the description provides the essential context: it lists all sessions and the information returned (status and iteration counts). It does not specify exact return shape or ordering, but the simplicity of the operation makes that a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the baseline is 4. The description correctly focuses on the output rather than parameters, and there are no parameter semantics left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a specific resource ('all refinement sessions'), and it names the returned fields ('status and iteration counts'). It also distinguishes itself from sibling get_session by the word 'all', so an agent can tell them apart without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for enumerating all refinement sessions, but it does not explicitly say when to prefer it over get_session or when not to use it. There are no exclusions or alternative routing, so the agent must infer the appropriate context from the word 'all'.
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 behavioral disclosure itself. It transparently states the Workbench engine choice and that PNG file paths are returned. However, it does not disclose side effects such as file creation/overwrite behavior, temporary output directory defaults, or whether the scene/camera is modified during rendering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The core action is front-loaded, followed by engine rationale and return value. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with fully documented schema parameters, the description is largely complete: it explains the purpose, engine, and output. It could be improved by mentioning default behavior (all four angles, temp directory) and whether the render modifies scene state, but these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, including enum values for angles and defaults. The description adds no additional parameter-level meaning beyond what the schema already provides, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Render an object from multiple angles (front, right, top, perspective)'. It also names the purpose ('for visual feedback'), which distinguishes it from single-frame or animation rendering siblings like blender_render_image and blender_render_animation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it: for quick visual feedback, using the Workbench engine 'for speed'. It does not explicitly mention alternatives or when not to use it, but the purpose and engine hint are enough to guide selection in most cases.
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 behavioral burden. It explicitly states the destructive scope: all objects are removed from the current scene. It does not mention irreversibility or effects on collections/materials, but the core destructive behavior is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the verb, the target, and the scope with no filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter destructive command, the description is largely sufficient: it names exactly what will be affected. It could add a caution about irreversibility or what is not cleared, but the essential context for invoking the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing additional to explain. The description correctly focuses on the operation itself rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('all objects from the current scene'), making the operation unambiguous. It is clearly distinguishable from sibling tools like blender_object_delete or blender_object_list by its scene-wide 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. It does not mention that blender_object_delete should be used for removing individual objects, or that blender_scene_new might be preferred when a fresh scene is needed. The usage context is only implied by the description.
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 behavioral burden, and it does a good job: it discloses that the tool creates a duplicate, applies remesh, auto-UV unwraps, and optionally bakes displacement. It could add more detail about post-conditions like the final object name or whether the original remains untouched, but the core side effects are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose statement, followed by a compact pipeline summary. The final sentence about game-ready asset production is somewhat promotional and adds little functional value, but the overall length and structure are appropriate for a multi-step tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow and parameter semantics are handled by the schema, but there is no output schema and the description does not explain what the tool returns or names the resulting object. For a mutating pipeline, a bit more detail on post-conditions would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 mentions voxel/quadriflow remesh and optional displacement baking, but these are already present in the schema, so it adds little parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it converts a high-poly sculpt into a retopologized low-poly mesh with optional displacement baking. It is clearly distinguishable from sibling tools like blender_sculpt_remesh_voxel or blender_bake_highpoly_to_lowpoly because it explicitly frames itself as a full pipeline rather than a single operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: converting a sculpted mesh to a game-ready low-poly asset in one pipeline step. It does not explicitly name alternatives or state when not to use it, but the pipeline framing makes the intended context obvious.
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 the full burden, and it does well: it discloses that the tool switches to Cycles, iterates channels, creates temporary images, configures bake settings, saves maps to disk, and returns a path dict. This meaningfully informs the agent of state changes and file outputs. It could add caveats about overwriting files, UV requirements, or the permanence of the engine switch, but the major behavioral traits are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler. The main capability is front-loaded, the process steps are compactly listed, and the return type is stated at the end. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 11-parameter bake operation with no annotations and no output schema, the description covers the return value and high-level process but omits important operational context: prerequisites like UV maps or materials, potential overwrite behavior, runtime cost, and whether the Cycles switch is persistent. The schema covers parameters, but the operational envelope is not fully described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline applies. The description mostly restates what the schema already says about channels and output files, adding little beyond process context. It does not clarify parameter interactions, defaults, or edge cases, but the schema fully documents each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Bake ALL PBR texture channels in one call.' It enumerates the exact channel set (DIFFUSE through COMBINED) and ends with a concrete return value. This clearly distinguishes it from sibling bake tools like curvature, ID map, or vertex-color baking, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'ALL PBR texture channels in one call' gives a strong contextual cue for when to use this tool: when multiple PBR maps are needed from a single bake operation. It does not explicitly state when not to use it or name alternatives among the many bake-related siblings, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 of disclosing behavior. The verb 'List' and the phrase 'Returns a nested tree structure' clearly indicate a read-only operation, and the description states exactly what information is reported. It stops short of explicitly saying 'does not modify the scene,' but for a listing tool this is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The core action and scope are front-loaded, and the return shape is stated efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument, read-only listing tool, the description is complete. It specifies the scene scope, the included data fields, and the nested-tree return format, which compensates for the lack of an output schema. An agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing for the description to explain. Per the baseline for zero-parameter tools, this scores well because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('all collections in the scene'), and clearly distinguishes this from object-level or scene-level tools by enumerating the returned data: hierarchy, objects, visibility, and render state. It is unambiguous about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus siblings like blender_scene_info, blender_object_list, or blender_collection_visibility. The intended use is implied by the name and description, but no explicit context or exclusions 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?
With no annotations provided, the description carries a heavier burden. It usefully explains that bevel_depth creates a tube and extrude creates a flat panel, but it does not disclose whether the original curve is replaced/destroyed, what happens when apply_as_mesh is false, or how the two modes interact if both parameters are set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The core action is front-loaded, and the mode distinction is explained immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The essential purpose and mode selection are clear, and the schema documents all seven parameters. However, with no annotations and no output schema, the description misses important behavioral caveats such as the effect of apply_as_mesh=false and the ambiguity when both bevel_depth and extrude are set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaningful conceptual meaning beyond the schema labels by mapping bevel_depth to 'tube' and extrude to 'flat panel', which helps an agent choose the right parameter values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation, 'Convert a curve to mesh', and names two concrete output modes, bevel (tube) and extrude (flat panel). This clearly distinguishes the tool from curve creation, mesh editing, and geonode curve tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is for converting curves into meshes and even guides the agent between bevel tube and extrude flat panel modes. It does not explicitly name alternatives or when-not-to-use cases, so it stops one step short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It explains the flood-select and angle threshold mechanism, but it does not mention whether the selection replaces the current selection or adds to it, nor does it state that edit mode is required. These are common expectations for mesh selection tools and should be explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The primary action is front-loaded, and the use case is stated briefly. It is efficiently written and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must carry the full burden. While it covers the core behavior, it omits important operational context: whether the selection replaces or augments the current selection, the requirement to be in edit mode, and the exact effect on the scene. These gaps could lead to incorrect usage in a complex pipeline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 introducing the concept of coplanar selection and clarifying that the angle_threshold defines coplanarity ('within an angle threshold'), which goes beyond the raw schema. It also reinforces the seed face concept, giving slightly more meaning than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool flood-selects connected coplanar faces from a seed face, which is a specific verb-resource pair. It distinguishes itself from other selection tools by focusing on coplanar faces and flat panels, making it easy to differentiate from siblings like blender_mesh_select_shortest_path or blender_mesh_select_edge_loops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete use case ('Ideal for selecting body panels') and explains the mechanism (expanding within an angle threshold), which tells an agent when to reach for it. However, it does not explicitly mention alternatives or when NOT to use it, leaving some inference to the agent.
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 the full behavioral burden and handles it well: each of the six actions names its effect (adds/removes/rebuilds/applies/deletes), including the destructive nature of UNSUBDIVIDE, DELETE_HIGHER, DELETE_LOWER, and APPLY_BASE. Missing are failure modes (e.g., unsubdividing at level 1) and whether APPLY_BASE irreversibly bakes changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler: the purpose statement is front-loaded, and each action receives a compact behavioral clause. The description is dense but every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-mode mutating tool with no output schema and no annotations, the description covers the core semantics of every action but omits error conditions, prerequisites beyond the schema's hint, and important consequences such as data loss or the irreversibility of APPLY_BASE. Adequate for basic selection, but an agent is left guessing about edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, and the description adds real value beyond the schema by explaining what each action enum value actually does — the schema's 'Action to perform on the multires modifier' provides no per-value semantics. object_name is already self-explanatory in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ('multiresolution modifier levels for sculpting') and enumerates all six action variants with their precise effects. The action breakdown makes it clearly distinct from generic modifier tools like blender_modifier_configure and from blender_mesh_subdivide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool — when sculpting workflows require managing multires levels — but never explicitly contrasts it with overlapping siblings such as blender_modifier_configure, blender_mesh_subdivide, or blender_bake_from_multires. An agent must infer the boundary from the action names rather than being told.
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 explicitly frames the tool as a read-only probe/report operation and names the reported categories. It does not mention potential latency or what happens when backends are unavailable, but it is transparent about the core non-mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One dense, well-organized sentence. The action and scope are front-loaded, followed by a concise list of outputs and the optional parameter reminder. No filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple diagnostic tool with no required parameters and no output schema, the description is nearly complete: it lists the three output areas and the relevant 3D node names. The schema covers the optional parameter. Minor gaps around exact return structure and empty/failure behavior do not block correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains check_nodes as specific node class names with a default of all known nodes. The tool description adds no parameter-level meaning, but the schema fully handles it, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Probe') and resource ('AI backends'), and states concrete deliverables: which ComfyUI 3D nodes are available, GPU VRAM, and queue status. This clearly distinguishes it from nearby siblings like blender_ai_list_backends or blender_ai_generate_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for inspecting backend capabilities and node availability. It does not explicitly say 'use this before generating' or name alternatives, but the context is strong enough that an agent can infer when it is appropriate.
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 available, the description carries the full burden. It explicitly discloses that the tool creates endpoint markers, a connecting line, and a text label, and implies an additive, non-destructive operation. It does not cover persistence, repeat-call stacking, or return behavior, but the core behavioral effect is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. The action, input geometry, and output components are all covered efficiently, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition is adequate for a simple annotation creation tool: it explains the purpose, the geometry, and the visual result, and the schema fully documents parameters. It could be improved by noting whether repeated calls stack or replace annotations, how to remove them, and what the tool returns, but these are not blockers for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented. The description's mention of calculated distance adds minimal context beyond the schema and does not meaningfully clarify offset, units, or label semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Add'), a specific resource ('a dimension line between two 3D points'), and the concrete output it produces ('endpoint markers, a connecting line, and a text label'). This clearly distinguishes it from generic annotation tools and from measurement siblings like surface area or volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear: annotate the distance between two 3D points. It does not explicitly name alternative tools or exclusion conditions, but the context is obvious enough that an agent can decide when to invoke it.
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?
It discloses a meaningful side effect: 'Temporarily overrides materials with emission shaders, bakes EMIT, then restores originals.' This is valuable behavioral context beyond the input schema, especially with no annotations present, and reassures the agent that original materials are restored.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no wasted words. The first sentence states the action and mechanism; the second provides the main use case. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description covers purpose, behavior, and typical use well. It could mention prerequisites like a UV map or assigned materials, but the description still gives an agent enough to decide whether and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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's mention of per-material/object/face-set assignment mirrors the color_mode enum but adds no new parameter-level detail. It correctly frames what the parameters achieve, but the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Bake a color ID map', a specific verb-plus-resource statement, and immediately clarifies the output: distinct flat colors per material, object, or face set. This clearly distinguishes it from sibling bake tools like blender_bake_pbr_batch or blender_bake_curvature, which target different map types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description supplies a concrete use case: 'Essential for texture painting workflows and Substance Painter masks.' This tells an agent when to select this tool. It does not explicitly list alternative bake tools or state when not to use it, but the context is clear enough.
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 behavioral burden. It transparently describes the multi-step process: creating a vertex color layer, baking to a temporary image, and transferring pixel data via UV lookup. It does not mention whether existing vertex colors with the same layer name are overwritten or that a UV map is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two front-loaded sentences with no filler: first states the purpose, second explains the process, and the use case is included efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description supplies the core purpose, process, and practical motivation, which is fairly complete. Remaining gaps are lightweight: no explicit prerequisite warning about UV maps and no note on overwriting existing vertex color layers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds general context about UV lookup and performance but no parameter-specific guidance beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: baking lighting or material information to vertex colors. It also explains the mechanism, which clearly distinguishes it from sibling bake tools that bake to textures or maps rather than vertex colors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use context: mobile/performance rendering where texture lookups are expensive. However, it does not explicitly mention alternatives among the many sibling bake tools or state when not to use this tool.
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 the behavioral disclosure burden. It explicitly states the object is scaled uniformly and that transforms are applied afterward so the scale returns to (1,1,1), revealing the post-condition and mutation behavior. It could mention prerequisites such as object existence, but the core side effects are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the essential action, purpose, and post-condition with no filler. The key operation is front-loaded, and the second sentence adds meaningful behavioral detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is sufficient given the 100% schema coverage and the tool's moderate complexity. It explains the operation, the result, and the coordinate/unit context well enough for an agent to invoke it correctly. It does not describe return values or error conditions, but no output schema exists and the operation's outcome is clearly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already fully documents all parameters. The description reinforces the concepts of 'known dimension' and 'chosen axis' but does not add new semantic detail beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Scale'), a resource ('an object'), and the exact purpose: matching a known real-world dimension along a chosen axis. It also distinguishes itself from generic transform tools by noting it applies transforms afterward so scale returns to (1,1,1), making the tool's specialized behavior clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it: when an object needs to be calibrated so a real-world measurement matches along a specific axis. It does not explicitly name alternatives like blender_object_transform or state when not to use it, but the specialized calibration context is unambiguous.
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 transparency burden. It does well by disclosing that the operation is non-destructive (adding a modifier, not baking/apply), that inputs can optionally be set, and that it returns the modifier name and current input state. It does not cover edge cases like object-type restrictions or error behavior, but core behavioral disclosure is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The main action and the return value are both stated efficiently and in a logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential context: what is being done, the optional input behavior, and what is returned. Since there is no output schema, the explicit return description is valuable. It could be more complete by mentioning prerequisites or failure modes, but it is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with descriptions and accepted value types, so the description adds little beyond noting that inputs are optional. This is the expected baseline given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action: apply an existing Geometry Nodes group to an object as a modifier, with optional input value setting. It distinguishes this from tool siblings like blender_geonode_create_group (which creates the group) and blender_modifier_add/configure (which handle modifiers more generically).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context clear: use this when you already have a Geometry Nodes group and want to attach it to an object as a modifier. It does not explicitly name alternative tools or state when not to use it, but its purpose is specific enough to guide selection.
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 the burden of revealing behavior. It does disclose that format detection is automatic, which is useful. However, it does not mention side effects such as adding objects to the current scene, potential unit/scale handling, or whether existing scene content is preserved, leaving some behavioral ambiguity for a mutation-like 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It conveys the core action, the resource, and the critical format information compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one required parameter and no output schema, the description is largely complete: it states the action and accepted formats. It could be slightly more explicit about the effect on the current scene, but the essential information for selecting and invoking the tool is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents filepath with 100% coverage, so the baseline is 3. The description adds value by enumerating the supported formats (glTF, FBX, OBJ, etc.), which directly informs what values filepath may take and helps the agent validate input before calling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Import') with a clear resource ('3D file') and enumerates supported formats, making it immediately obvious what the tool does. It also distinguishes itself from the many export-oriented siblings (e.g., blender_export_gltf, blender_export_fbx) by focusing on importing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for bringing external 3D files into Blender, and the auto-detection note tells the agent which formats are accepted. There are no competing import tools among the siblings, so explicit when-not guidance is unnecessary, though it could have mentioned that it adds objects to the current scene.
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 disclosure burden, and it covers the key trait: the operation happens in a 'temporary scene,' signaling a non-destructive, contained workflow. It also discloses the return contract ('returns the output path'). It does not explicitly confirm temp-scene cleanup, error behavior for nonexistent materials, or the time cost of Cycles, but the core safety-relevant behavior is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the purpose, the second enumerates the pipeline in order. Every clause earns its place, and the distinctive behavior (temporary scene) is front-loaded rather than buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description compensates by spelling out the full pipeline and the return value, which is the only source of return-type information. It differentiates from the large sibling set via the temporary-scene framing, and parameter usage is fully covered by the 100%-documented schema. Minor gaps remain—no explicit statement that the current scene is left untouched and no error-handling note—but nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all five parameters with defaults and enums, making 3 the baseline. The description adds light contextual meaning by mapping 'chosen shape' to preview_shape and 'output path' to the return value, but it contributes no syntax, constraints, or formats beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Render') followed by a concrete workflow: creates a temporary scene, assigns the material, renders it, and returns the output path. The 'standard shape' scoping makes it clearly distinguishable from scene-level render siblings like blender_render_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear usage context: this is for isolated material previews on a standard shape in a throwaway scene, which implicitly separates it from blender_render_image (renders the actual scene) and blender_material_assign (assigns a material in a scene). It never names an alternative or states explicit when-not-to-use conditions, so the agent infers the boundary rather than being told.
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 the full burden, and it does substantial work: it discloses that the tool computes three distance statistics, detects intersection/overlap, and returns the closest point pair. It also implies a read-only measurement operation, which is appropriate for this tool. It could additionally describe the sampling nature or return format, but the core behavioral traits are clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. It front-loads the core measurement behavior, then adds the intersection/closest-point output detail, then ends with a practical use case. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description appropriately communicates what the caller should expect: distance statistics, intersection detection, and closest point pair. The parameter schema covers the sampling behavior, and the use case helps disambiguate from sibling tools. A fully explicit return structure or unit explanation would improve completeness, but the current description is sufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema already documents all three parameters, including the accuracy/performance tradeoff of sample_count. The tool description adds no parameter-level detail beyond what the schema provides, so the 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Measure') and resource ('two mesh objects'), and spells out the exact quantities returned: minimum, average, and maximum distance. It also signals its distinct role among measurement siblings by mentioning intersection detection and collision/clearance checks, which separates it from surface area, volume, and edge angle tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The closing sentence, 'Useful for collision/clearance checks', gives a clear use-case context that helps an agent decide when to invoke this tool. It does not explicitly name alternative measurement tools or state when not to use it, but the context is specific enough to guide selection among the many sibling measurement 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?
With no annotations provided, the description carries the full disclosure burden and does so well: it states the non-destructive nature ('without modifying it') and what the call returns. It omits secondary behaviors like handling of empty selections or edit-mode prerequisites, but the essential safety and output contract are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero wasted words: the action and the critical non-mutation qualifier are front-loaded, and the second sentence precisely states the return value. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, read-only query tool with full schema coverage, the description covers the core contract: purpose, safety, and return content. Missing details are minor edge cases (empty selection behavior, edit-mode prerequisites, exact response shape absent an output schema), so it is nearly complete but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds modest value by mapping the mode enum to return types (vertices/edges/faces), but it doesn't explain syntax, defaults, or mode-specific behavior beyond what the schema states, landing at the high-coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Query') with a clear resource ('current mesh selection state') and specifies the return content (indices of vertices, edges, or faces). The 'without modifying it' clause sharply distinguishes this from mutating siblings like blender_mesh_select, so an agent can differentiate it from the many selection-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'without modifying it' phrasing establishes a clear read-vs-write context that tells an agent when to reach for this tool rather than a selection mutation tool. However, it never names an alternative explicitly or states a when-not-to-use condition, so the guidance stops short of being fully explicit.
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 of behavioral disclosure. The verb 'List' clearly implies a read-only operation and no side effects are hinted, but the description does not explicitly state that scene state is unchanged or how a missing/invalid object_name is handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with the action front-loaded. Every word earns its place, and there is no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-optional-parameter read-only tool, the description and schema together cover both invocation modes sufficiently. It lacks explicit return-format or not-found error behavior, but the low complexity means this is a minor gap rather than a critical omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3, and the description adds meaningful semantics by explaining that omitting object_name switches to listing available modifier types. This helps an agent understand the optional parameter's mode-switching behavior beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resources ('modifiers on an object' or 'available modifier types'). It is immediately distinguishable from sibling modifier tools like blender_modifier_add, blender_modifier_remove, and blender_modifier_configure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear conditional guidance: provide object_name to list an object's modifiers, or omit it to list all available modifier types. It doesn't explicitly name alternatives, but inspection context is clear since this is the only listing tool among the modifier siblings.
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 the full burden. It transparently states the tool checks specific rig characteristics and returns a list of issues plus a compatibility score, making its read-only validation behavior reasonably clear. It does not explicitly guarantee that no modifications occur, but 'validate' combined with the output description strongly implies a non-destructive check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence establishes the tool's purpose, the second sentence lists what is checked and what is returned, making the description easy to scan and act on.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, inputs at a high level, validation areas, and return value shape. Since there is no output schema, mentioning the return type is valuable. It could go slightly deeper on issue format or side-effect guarantees, but for a validation tool with simple parameters, the description is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already documented. The description adds context by linking 'target format' to the returned compatibility score, but it does not provide additional parameter-level semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (validate), a clear resource (armature rig), and a specific purpose (export compatibility). It enumerates concrete checks and distinguishes itself from mesh/dimension validation tools by focusing on rig-specific properties and target formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage before exporting an armature rig and frames validation against a target export format. It does not explicitly name sibling alternatives like blender_validate_mesh_quality or blender_msfs_validate_for_export, but the context is unambiguous enough for an agent to select this tool over general mesh validation.
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 behavioral disclosure burden. It explains what the tool does and describes each criterion's grouping behavior, but it does not disclose side effects such as whether existing face sets are replaced, appended, or otherwise affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main action comes first, followed by a concise enumeration of all criteria. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with a fully described enum and a clear sculpting use case, the description is nearly complete. It lacks only explicit notes about existing face-set behavior and prerequisites, which are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaningful enrichment by explaining each enum value: LINKED, MATERIAL, NORMAL, SHARP_EDGES, and UV_ISLAND. This goes beyond the schema's terse 'Criteria for creating face sets.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create face sets by grouping faces based on criteria.' It also clearly distinguishes itself from sibling sculpt and mesh tools by focusing on face-set partitioning for isolated sculpting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the intended use case: face sets partition the mesh into regions for isolated sculpting. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough for an agent to infer when this tool is appropriate.
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 behavioral burden. 'Get' strongly implies a non-mutating read operation, and the list of returned information (name, frame range, render settings, object count) communicates what to expect. It does not explicitly state read-only or describe output format, but it is not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that immediately identifies the action and resource, then efficiently lists the key returned fields. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only information tool with no output schema, the description covers the essential purpose and expected content. It could mention output format or explicitly say no scene modification occurs, but the current wording is sufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter semantics are not a burden. The baseline for zero-parameter tools is 4, and the description adds no unnecessary parameter detail while correctly standing on its own.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('current scene information') and enumerates concrete contents: name, frame range, render settings, and object count. This distinguishes it from scene-mutation siblings like blender_scene_new and blender_scene_clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the read-only inspection tool for scene state, distinct from scene mutation or version-checking tools. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent.
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 states it returns node group name, inputs, and outputs, and the modifier_name parameter behavior (defaults to first modifier) is described. However, it does not explicitly state that the tool is read-only, nor does it describe error behavior (e.g., if no geometry nodes modifier exists). This is a minor gap given the clear read intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The core action is front-loaded, and the return contents are listed succinctly. Every word contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 2 params and no output schema, the description provides everything needed: what it does, what it returns, and when to use it. It also mentions the sibling geonode_apply for the next step. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters having descriptions. The object_name is straightforward, and modifier_name includes the default behavior. The description adds no new parameter-specific details beyond what the schema already provides, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the current Geometry Nodes setup on an object, lists the exact return contents (node group name, input names/types/current values, output names), and explicitly ties it to the geonode_apply sibling for the tweaking workflow. This distinguishes it from other tools and makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Useful for introspection before tweaking values with geonode_apply', which tells the agent exactly when to use this tool and names the alternative (geonode_apply) that should follow. It implicitly excludes other inspection tools like blender_object_get by focusing on Geometry Nodes.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/SekaiNoOwari77/mcp-3d-modeling-agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server