Blender MCP

by harveyxiacn

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.3.1
Disambiguation4/5
Most tools are clearly distinct, but blender_get_viewport_screenshot and blender_snapshot_viewport have highly overlapping purposes, potentially confusing an agent.
Naming Consistency5/5
All tools use a consistent snake_case naming with a clear pattern: resource-specific tools are prefixed with blender_<resource>_ (e.g., blender_object_, blender_scene_) and general actions are blender_<action>_<object>, making the overall pattern predictable.
Tool Count2/5
With 38 tools, the count exceeds the 'too many' threshold of 25+. While Blender is complex and the skills system helps, the base set is still large and may overwhelm context windows.
Completeness3/5
The base tool set covers core scene and object operations, export, and file I/O, but lacks tools for materials, modifiers, animations, and other essential Blender workflows. The skills system can fill gaps, but as presented, notable operations are missing.
Average 3.5/5 across 38 of 38 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- Last stable release on June 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description does not disclose behavioral traits like whether undo reverts changes or requires prior actions. The return value 'Undo result' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (3 lines), but it is not verbose. However, it is too brief and lacks substance, making it merely adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present but not described, the description offers no details about return values or errors. It does not mention prerequisites or limitations like the steps range (1-100).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'steps' parameter as 'Number of undo steps'. The description repeats this without adding new meaning, so it provides no extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Undo operations' which is clear in a general sense but does not specify what kind of operations can be undone or the scope (e.g., last user action, within a session). It is not a tautology, but it adds little beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like blender_redo or other undo mechanisms. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description could add value by clarifying that saving overwrites the file and that the default compression is true. It does not mention behavior when filepath is null or the return value contents. Contradictions: none.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and uses an Args/Returns structure, which is good. However, it is under-specified; conciseness is not valuable if it omits essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one param (nested) and no output schema shown, the description is incomplete. It does not explain what 'Save result' means or whether the tool returns a path or status. With annotations providing idempotent hint, the description still lacks details about the save behavior and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% per context, but the schema itself has descriptions for compress and filepath. The description's 'File path and compression options' is vague and does not explain that filepath defaults to null meaning 'use current file' or that compress defaults to true. It adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save the Blender file,' which is a specific verb+resource action. This distinguishes it from sibling tools like blender_file_open (open) and export tools (export to formats). However, it could be more precise about whether it saves to the current file path or prompts for a new location.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like blender_export_fbx or blender_file_open. The description gives no context for when not to use it or what prerequisites exist (e.g., file must be open).
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 adds no behavioral context beyond the annotations. Annotations already indicate it's not read-only, but the description doesn't elaborate on state changes or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it could benefit from a brief phrase like 'Inverse of undo' without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description remains vague. It doesn't clarify what 'operations' are redone or what 'Redo result' means, leaving gaps for a simple but standard operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'steps' is described as 'Number of redo steps' in both the description and schema, so it adds no new meaning beyond the schema. Schema description coverage is present, scoring baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Redo operations,' which is a specific verb and resource, but it's vague and does not differentiate from the sibling tool 'blender_undo'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like blender_undo. Lacks context about being the inverse of undo.
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 behavioral traits beyond the annotations. For an export tool, details about file overwriting, side effects, or required permissions are absent. Annotations indicate idempotentHint=true and destructiveHint=false, but the description adds no clarification about what happens on repeated calls with the same filepath.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant lines like 'Args: params: Export settings' and 'Returns: Export result', which do not add value beyond the schema and annotations. The core purpose is stated in one sentence, but the additional text is unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with a nested object, an output schema, and many siblings, the description is too sparse. It does not explain what the export result contains, how the tool integrates with Blender's file system, or any limitations. The output schema exists but is not leveraged to reduce burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description groups parameters as 'Export settings' without adding meaning beyond the input schema. Since the schema already provides detailed descriptions for filepath, selected_only, apply_modifiers, and export_materials, the description's contribution is minimal. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Export as OBJ format' clearly states the verb 'export' and the resource 'OBJ format', distinguishing it from siblings like blend_export_fbx. However, it does not explicitly mention that it exports from the current Blender scene, which is implied by the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use OBJ export versus alternatives like FBX or GLTF. It lacks any context about file format tradeoffs, such as OBJ's support for geometry but limited animation or material data. This omission forces the agent to rely on external knowledge.
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 already provide readOnlyHint=true and destructiveHint=false. The description adds no additional behavioral details, such as output format, side effects, or requirements (e.g., presence of a 3D view). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using two sentences plus an arg list. It is front-loaded with the core purpose, but the args section could be more structured (e.g., bullet points).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of rich annotations and schema, the description is adequate but misses key context: output format, default output path behavior, and differentiation from similar tools. It is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides detailed descriptions for width, height, and output_path. The description only vaguely mentions 'Output path and dimensions', adding little beyond schema. Since schema coverage is complete, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a screenshot of the current viewport, using a specific verb and resource. However, it does not differentiate from sibling tools like blender_snapshot_viewport, which may have similar functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or exclusions, leaving the agent without context for appropriate invocation.
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 adds minimal behavioral context beyond the annotation (destructiveHint: true). It does not mention that original objects are removed or that the operation is irreversible, which would be valuable for a destructive 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with two sentences. The first sentence clearly states purpose, the second repeats argument and return info. It is efficient, though the second sentence is somewhat redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool that modifies the scene, the description lacks important context such as prerequisites, what happens to original objects, error conditions, and behavior details. Even with an output schema, the description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters ('target' and 'objects'), so the description's mention of params adds no new information. Baseline of 3 is appropriate given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Join multiple objects into one,' specifying the action and resource. The name and description distinguish it from sibling object manipulation tools like delete or duplicate, though no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The usage is only implied by the tool name and short 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?
Description adds no behavioral context beyond annotations (idempotentHint, destructiveHint, readOnlyHint). It does not disclose renaming behavior (e.g., uniqueness constraints, side effects on relations). Score 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but includes verbose docstring boilerplate ('Args:', 'Returns:'). Front-loading is decent. Score 3.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good annotations and schema, description omits details like naming rules, case sensitivity, or what happens on duplicate names. Output schema existence is not leveraged. Score 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description merely restates parameter names ('Current name and new name') already defined in schema with descriptions. No additional semantic or usage detail. Score 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Rename an object' — a specific verb and resource. Among siblings, there is no other rename tool, so differentiation is inherent. Score 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., object_duplicate, object_transform). No context about prerequisites or typical scenarios. Score 2.
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 already provide idempotentHint=true and destructiveHint=false, indicating safe behavior. The description adds no further behavioral context, such as file overwrite behavior or prerequisites, and does not elaborate on the return value beyond 'Export result', which is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with clear sections for purpose, arguments, and returns. It is front-loaded with the main action. However, the 'Returns Export result' is trivial and could be omitted or expanded, so not all sentences are fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown but flagged as present), the description does not need to detail return values. It provides the core purpose and usage hints, but lacks details on prerequisites, error states, or interaction with the Blender scene. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has detailed descriptions for all six parameters, so the schema coverage is effective. However, the description itself adds no extra meaning or context to the parameters; it simply references 'params' generically. With a schema coverage of 0% from the description, it fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export as glTF format' with a specific verb and resource. It provides context about suitability for Web and Three.js, but it does not explicitly distinguish from sibling export tools like blender_export_fbx or blender_export_obj, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a hint about when to use this format ('suitable for Web, Three.js, etc.'), implying usage context. However, it lacks explicit guidance on when not to use or direct comparisons with other export tools, resulting in only implied usage.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it retrieves version and status, which aligns with these hints but doesn't disclose additional behavioral traits like what exactly 'status' covers or any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines) but includes a 'Returns' line that repeats information likely already in an output schema. It is concise but lacks structure and valuable detail for the user.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (as per context signals), the description doesn't need to elaborate on return values. However, it is incomplete regarding the input parameter and the exact nature of 'status information'. It's minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'params' which is an empty object. The description does not explain this parameter or its purpose. With 0% schema description coverage, the description fails to compensate by clarifying that no actual parameters are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets 'Blender version and status information', which is a specific verb-resource combination. It distinguishes from siblings like 'blender_connection_status' which focuses on connection state, not version/status of Blender itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't differentiate from 'blender_connection_status' or explain when to use one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true and destructiveHint=false. Description adds little beyond the bare purpose, not disclosing that settings are overwritten or that operation is safe. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short: one sentence plus bullet-like Args/Returns. No wasted words, but could be more structured with explicit parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one complex parameter with multiple fields, schema descriptions are minimal, and annotations exist, the description is adequate but incomplete. It doesn't mention the scene_name parameter or idempotent nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% according to context, and the description only says 'params: Scene settings parameters' without explaining each field's meaning, constraints, or defaults. Schema has minimal descriptions like 'Frame rate' but description doesn't compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Set scene settings' and lists examples like frame range, frame rate, unit system, which clearly indicates the verb and resource. It distinguishes from sibling scene tools (create, delete, get_info) but lacks clarity on whether it applies to active scene or specified scene via scene_name parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like blender_scene_create or blender_scene_get_info. No when-not-to-use or prerequisites 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?
Annotations already mark the tool as destructive (destructiveHint=true). The description adds that the current scene is replaced and unsaved changes are lost, which aligns with and reinforces the annotation. No additional behavioral details (e.g., authentication, rate limits) are provided, so it adds marginal value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the main action. It uses a clear 'Note:' for critical warnings and structured 'Args:' and 'Returns:' sections. However, the parameter section is incomplete, which slightly detracts from its efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description's 'Returns: Open result' is vague. The tool involves two inputs (filepath and load_ui), but the description only covers one. The critical warning about scene replacement is good, but the overall completeness is lacking given the tool's complexity. An output schema exists, so no need for return details, but parameter coverage is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a nested object with two parameters (filepath and load_ui), but schema description coverage is 0%. The description only mentions 'params: File path', ignoring the load_ui parameter entirely. It fails to compensate for the lack of schema descriptions and does not explain file path formats or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a Blender file, which is a specific verb-resource pair. It differentiates from sibling tools like blender_file_save and export tools. However, it could be more specific about the optional UI loading functionality, so it's not a perfect 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that opening a file replaces the current scene and unsaved changes are lost, which provides crucial usage context. However, it does not give explicit guidance on when to use this tool versus alternatives (e.g., blender_file_save for saving, or other file operations), and there are no 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?
Annotations provide no safety profile (all hints false). The description does not disclose critical behavioral details such as whether creation fails on duplicate name, overwrites, or depends on an open Blender file. It only states the basic action without 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences plus structured Args/Returns. The main point is front-loaded. Slight deduction for including redundant parameter descriptions that repeat the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool, the description covers the basic purpose and parameters, but lacks specifics about error behavior, naming rules, or the structure of the return value. Given the output schema exists but is not detailed, the description could do more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description should compensate by adding meaning. However, it merely restates 'scene name and optional copy source' which adds no value beyond the schema's property descriptions. No examples, constraints, or formatting hints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new scene in Blender' with a specific verb and resource. It mentions optional copying from an existing scene, distinguishing it from sibling tools like blender_scene_delete or blender_scene_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to create a new scene vs. copy from an existing one, or handling duplicate names. The 'optionally copied' hint is too minimal to be considered explicit usage 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?
Annotations indicate idempotency and non-destructiveness, but the description adds no extra behavioral context (e.g., file overwriting, side effects). The description is neutral and does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the args/returns section is vague and not helpful. It is concise but lacks informative structure; every sentence is minimal but does not add value beyond the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of FBX export (many parameters), the description is highly incomplete. It does not explain behavior like file overwriting, the role of presets, or return value specifics. The existence of an output schema mitigates only slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely says 'params: Export settings', adding no meaning beyond the input schema. However, the schema itself contains detailed property descriptions (with 100% property descriptions), so the baseline is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports as FBX format and notes suitability for Unity/Unreal, distinguishing it from sibling export tools (gltf, obj). It is specific about the resource and action, but does not explicitly list the 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting to FBX for game engines, but provides no explicit guidance on when to choose this over blender_export_gltf or blender_export_obj. No when-not or alternative comparison is 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?
destructiveHint annotation already indicates destructive behavior. Description adds no additional insights like irreversibility or confirmation. With annotation, bar is lower, but description adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Brief and to the point with Args/Returns structure. No fluff, but could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with output schema present, the description is minimally acceptable. Lacks mention of error conditions or prerequisites like object existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 2 parameters but description only vaguely mentions 'Object name and deletion options'. The delete_data parameter is not explained in description, and schema coverage is 0%. Description fails to add meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it deletes an object, but lacks differentiation from sibling tools like duplicate, rename, etc. It is specific enough for a delete 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies deletion but does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's statement 'Get detailed information' aligns. However, the description adds no additional behavioral context beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded main sentence. The Args and Returns sections are present but add little detail. No obvious redundancy, though the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and good annotations, the description adequately states the tool's purpose and inclusions. However, it is vague on 'other info' and does not mention the 'include_transform_check' parameter's detailed purpose, leaving some incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only says 'params: Object name and inclusion options', which is generic. The input schema already provides detailed descriptions for all parameters (high coverage), so the description adds minimal value beyond summarizing the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about an object', specifying what is included (transform, mesh statistics, modifiers, materials). However, it does not differentiate from sibling tools like blender_describe_object, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as blender_describe_object or blender_get_info. The description does not state prerequisites, context, 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?
Annotations already indicate the tool is idempotent, non-destructive, and non-read-only. The description adds that it can set absolute or delta transforms, which is a useful nuance not captured by annotations. However, it does not elaborate on side effects or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two focused sentences, no wasted words, and front-loaded purpose. It is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about how this tool fits with siblings (e.g., difference from apply_transform), does not mention return values despite an output schema, and omits details like object existence prerequisites or behavior when called on non-existent objects. The output schema exists but the description doesn't leverage it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all parameters (name, scale, location, rotation, delta variants), so the description adds no additional parameter meaning. Baseline of 3 is appropriate given high schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it transforms an object with location, rotation, and scale, covering absolute and delta transforms. However, it does not explicitly distinguish itself from sibling tools like blender_object_apply_transform, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds minimal behavioral context: it states creation happens but does not disclose side effects (e.g., adding to the active scene, handling of duplicate names, or whether the object is selected after creation). The return value 'Creation result' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: three brief paragraphs covering purpose, types, and parameters. It front-loads the core action ('Create a new object') and avoids extraneous detail. Every sentence serves a function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (21 object types, optional mesh_params with many sub-parameters), the description omits details about result structure, default values, and error conditions. However, the schema and output schema presumably cover those. The description is minimally sufficient but could better connect parameters like mesh_params to specific object types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists key parameters ('type, name, location, rotation, scale') but adds no meaning beyond the schema's own descriptions. Given that schema description coverage is 0%, the description does not elaborate on format, constraints, or relationships (e.g., which types support mesh_params). The schema provides detailed definitions per property, so the description's value is limited to a quick summary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new object in Blender' with a clear verb and resource. It distinguishes itself from sibling tools like blender_object_delete or blender_object_duplicate by focusing on creation, and it lists supported object types (meshes, curves, text) to clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools such as blender_object_duplicate or blender_object_rename exist, but the description does not specify scenarios like 'Use this for new objects, not for duplicating existing ones.' The lack of context leaves the agent to infer usage.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that filtering is possible, which is consistent. However, it does not disclose other behavioral traits like response format (though inferable from schema) or performance implications. With good annotation coverage, the description's contribution 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with a clear separation of purpose, args, and returns. It avoids unnecessary words. However, it could be more structured by listing the filter options explicitly without relying on the schema alone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has nested parameters and an output schema exists, the description is minimally complete. It mentions filtering but omits details about the output (e.g., what 'Object list' contains). The presence of an output schema partially compensates, but the description could be more informative for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's 'Args: params: Filter and format options' adds no meaning beyond the input schema, which already has detailed descriptions for the nested properties (limit, type_filter, name_pattern, response_format). Since the schema provides these descriptions, the tool description fails to add value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists objects in the scene, with optional filtering by type or name. This distinguishes it from sibling tools like blender_scene_list (which lists scenes) and blender_describe_object (which details a single object). The verb 'list' and resource 'objects' are specific and 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., blender_describe_object, blender_scene_list). The description only states what the tool does, not when it should be preferred. Given the many sibling tools, this omission reduces helpfulness for an AI agent deciding between 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?
Annotations already indicate non-read-only, non-destructive, and idempotent behavior. Description adds that selection can be done by name or wildcard, but does not elaborate on side effects (e.g., clearing previous selection) beyond what is in the schema parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but includes boilerplate 'Args:' and 'Returns:' lines that do not provide useful information beyond the parameter names. Could be more efficient by removing these boilerplate lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is minimally adequate. It lacks mention of the active scene context or any preconditions, but these are either inferred or covered by the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions already document each parameter (names, pattern, set_active, deselect_all) with clear meaning. The description only says 'params: Selection parameters' which adds no value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Select objects' with the ability to use name list or wildcard pattern, which is a specific verb+resource. It is distinct from sibling tools like blender_object_list (which likely lists without selecting) and blender_object_create (which creates new objects).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as blender_object_list or blender_object_activate. No mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and destructiveHint=false, but the description adds no extra behavioral context beyond the action itself. It doesn't disclose side effects, error handling, or what happens if the scene name is invalid, so it fails to enhance transparency beyond what annotations already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with only one functional sentence, and it front-loads the purpose. However, the 'Returns' section is vague ('Switch result') and could be omitted or clarified. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with annotations and an output schema, the description is minimally adequate. It covers the core action but omits details like error conditions (e.g., nonexistent scene) or behavior when switching to the current scene. It lacks completeness for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already defines 'scene_name' with a description 'Name of the scene to switch to,' which is more informative than the description's 'Target scene name.' Since schema description coverage is effectively low (0% as per context), the description should compensate, but it does not add value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Switch to the specified scene,' which uses a specific verb ('switch') and resource ('scene'). This distinguishes it from sibling tools like blender_scene_create, blender_scene_delete, and blender_scene_list, 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention when not to use it or any prerequisites (e.g., ensuring the scene exists). It only describes the action without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states that activating a skill registers new tools for immediate use, but it does not address important behaviors such as whether multiple skills can be active simultaneously, if activation is reversible (though deactivate exists), or any side effects like overwriting previously loaded tools. The description lacks depth on the mutation's consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise at five sentences plus an Args section. It front-loads the main purpose and then adds supporting details. There is no noticeable fluff, and the information is well-ordered. A small improvement could be to integrate the Arg description more tightly, but it is already efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity (one required parameter) and an output schema exists, so the description does not need to detail return values. It covers the purpose, prerequisite, parameter, and effect of activation. However, it omits whether activation is session-persistent or if errors can occur (e.g., invalid skill name). Given the simplicity, these gaps are minor but notable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage (no description for the 'skill_name' parameter), so the description must compensate. It adds examples ('modeling', 'materials', 'animation') and describes the parameter as 'Name of the skill to activate'. While helpful, it does not specify valid values, format, or that the name must come from 'list_skills', which is only mentioned earlier. The guidance is adequate but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'activate a skill' and explains that it dynamically loads the skill's tool group, registering new MCP tools. It also mentions that each skill provides related tools and a workflow guide. However, it does not explicitly distinguish from its sibling 'blender_deactivate_skill', which would be the reverse operation, missing some 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to use 'list_skills' first, establishing a clear prerequisite. It implies the tool is used to load a skill's tools for immediate use. While it doesn't explicitly state when not to use or mention alternative tools like 'deactivate_skill', the context is clear enough for typical usage.
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?
Annotations already provide destructiveHint: true, readOnlyHint: false, openWorldHint: true. The description reinforces the dangerous nature ('may modify the scene or perform dangerous operations'), adding useful context but not going beyond what annotations already convey. The return is vaguely described as 'Execution 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise – two sentences plus structured Args/Returns. Front-loaded with purpose and caution. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a powerful and potentially dangerous tool, the description lacks details on execution context (Blender API access, error behavior), return value format (despite an output schema existing), and specific usage scenarios. The caution is helpful but incomplete for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's 'Args: params: Python code and timeout' merely restates parameter names from the schema, which already includes brief descriptions. With schema_description_coverage effectively high (schema fields have descriptions), the description adds zero new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute Python code in Blender' – a specific verb and resource. This distinguishes it from sibling tools that perform discrete Blender operations (create, delete, transform).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a caution about modifying the scene, implying careful use, but does not provide explicit when-to-use/when-not-to-use criteria or alternatives. No guidance on when to rely on this tool versus other specific operations.
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?
Annotations provide idempotentHint=true and destructiveHint=false, indicating safe mutation. The description adds no further behavioral details such as side effects on object transforms or interaction with existing parent relationships. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at two sentences, front-loaded with the primary action. No redundant information, every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and annotations cover safety, the description lacks details about return value (just 'Setting result'), error handling, or prerequisites. It is adequate but not fully complete for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already includes clear descriptions for each parameter (child_name, parent_name, keep_transform). The tool's description only summarizes 'Child object and parent object names', adding minimal value. Schema coverage is effectively high, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the parent-child relationship for objects' clearly states the action and resource. The title from annotations reinforces this. It is distinct from sibling tools which handle other object operations like transforms, creation, deletion, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, prerequisites, or contexts where it should be avoided. There is no mention of when to set vs clear parent, or how it relates to other hierarchy tools like blender_describe_hierarchy.
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?
Annotations already declare read-only, idempotent, non-destructive. The description adds value by specifying it returns current scene if scene_name is empty, providing default behavior context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and structured with Args/Returns sections. However, the Args section redundantly restates schema content, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with an output schema, the description adequately covers what the tool does and returns. Could mention more about return format but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats schema info about the optional scene_name parameter without adding new meaning. Schema coverage is high (inner property has description), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets detailed scene information, listing specific return values like frame range, FPS, unit settings. It distinguishes from sibling tools like blender_describe_scene by focusing on 'detailed info' but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like blender_describe_scene or blender_get_info. The description simply states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive behavior. The description adds that duplication can be independent or linked, but does not disclose other traits like permissions, undo behavior, or error states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and an Args listing. No extraneous information, but the Args section is somewhat redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the vague 'Returns: Duplication result' is acceptable but lacks details on failure modes or side effects. The description covers the core functionality but misses context like object existence checks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides brief descriptions for all parameters. The tool description lists the same parameters in an Args line but adds no additional detail about formats or defaults. Baseline 3 since schema coverage is present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'duplicate' and the resource 'object', and distinguishes between independent and linked copies. This differentiates it from siblings like blender_object_create (creates new) and blender_object_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies duplication use cases but does not explicitly state when to use this tool versus alternatives or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, idempotent, and non-destructive. The description adds that it returns indented text or JSON (via format parameter) and shows the full tree. However, it does not mention behavior like ordering, depth limits, or performance considerations, which would add value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the purpose and output formats, and the second provides an example. It is efficient and front-loaded, though the example is somewhat generic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter with a well-described schema and an output schema exists, the description covers the essential purpose and output options. It lacks details like ordering but is adequate for the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has descriptions for the format parameter and its enum values, covering the single parameter well. The description reinforces this by saying 'as indented text or JSON', but adds no new semantic 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the full parent-child object tree of the scene', which is a specific verb and resource. It distinguishes from sibling tools like blender_describe_object (single object) and blender_describe_scene (scene settings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example use case ('to understand how objects are organized and parented') but does not explicitly state when to use this tool versus alternatives like blender_describe_object or blender_object_get_info. No when-not conditions 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?
Annotations already declare readOnlyHint=false and idempotentHint=true, indicating a safe, repeatable write operation. The description adds no behavioral traits beyond the method options, like whether existing object data is preserved or if specific permissions are required. It conforms to annotations, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus Args/Returns sections. Every sentence adds value (purpose, method examples, parameter summary). No clutter or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a rich schema and annotations, the description adequately covers the core function and methods. The return value is noted but vague; however, the presence of an output schema (not shown here) compensates. It could mention prerequisites (e.g., object exists) but is largely complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has detailed descriptions for all parameters (name, center, origin_type), so the description's brief mention of 'Object name and origin type' adds minimal value. It omits the 'center' parameter entirely. Given schema coverage is effectively 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set the origin point of an object.' It lists multiple supported methods (geometry center, 3D cursor, bottom center for feet), which adds specificity and distinguishes it from sibling tools like blender_object_transform or blender_object_get_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (e.g., 'suitable for character feet') but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives. It lacks exclusions or context for when other tools might be preferred.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds value by specifying the returned fields (name, object count, other info) and output format options (Markdown/JSON), beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three short sentences. Front-loaded with the core purpose, followed by return info and parameter description. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema, the description sufficiently covers what is returned. It could mention error cases or prerequisites, but it is adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'params' with its nested 'response_format' field. The description only repeats 'Output format options' without adding new meaning or usage details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all scenes in Blender' with a specific verb and resource, distinguishing it from sibling tools like blender_describe_scene and blender_scene_get_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., blender_describe_scene, blender_scene_get_info). The description only states what it does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint, idempotentHint, destructiveHint) and adds value by specifying that the tool returns a file path for multimodal analysis. No contradictions. Slight bonus for the example illustrating expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an example. It front-loads the core purpose and avoids extraneous details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple snapshot tool, the description covers the return value (file path) and provides a usage example. It does not explain file naming conventions or differentiate from similar tools, but given the low complexity and rich annotations, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides clear descriptions for all parameters. The tool description does not add new parameter information beyond the example, which uses default dimensions. Schema coverage is high, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures the 3D viewport as a PNG image and returns the file path. However, it does not differentiate from the sibling tool 'blender_get_viewport_screenshot', which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example use case (capturing a scene layout) but does not explicitly state when to use this tool versus alternatives or provide when-not-to-use guidance. The context is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true, so the description's 'Delete' is consistent. It adds the last-scene constraint but does not disclose error behavior if trying to delete the last scene, nor how results are returned beyond 'Deletion 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences and a returns line. Every sentence adds necessary information; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the purpose and one constraint, but lacks details on error handling, what deletion entails, and specifics of the return value. 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The one parameter 'scene_name' is described both in schema and description. The description essentially repeats the schema's description, adding no new semantic meaning. With schema coverage effectively 100%, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a scene, with the note about not deleting the last scene. It distinguishes from sibling tools like blender_scene_create or blender_scene_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a critical constraint (cannot delete last scene) but does not explicitly state when to use vs. alternatives or provide exclusions. Among siblings, there is no other scene deletion tool, so confusion is minimal.
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?
Annotations indicate idempotentHint=true and destructiveHint=false. The description adds that it 'resets object transforms to default values' and 'applies transform data to the mesh data,' which is a key behavioral trait not fully covered by annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short paragraphs and a docstring-style Args/Returns section. It front-loads the primary purpose and includes only essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the presence of annotations and output schema, the description adequately covers purpose and effect. However, it omits details about what exactly 'apply transform' means in Blender (e.g., baking into mesh), which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for each property (name, scale, location, rotation), so the schema already documents parameters. The description only mentions 'Object name and transform types to apply' without adding meaningfully beyond the schema. With low schema description coverage, the description does not compensate significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies object transforms (location, rotation, scale) to mesh data and resets object transforms. This distinguishes it from sibling tools like blender_object_transform (which sets transforms without applying) and blender_object_set_origin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for applying transforms to mesh data but does not provide explicit guidance on when to use this tool versus alternatives like blender_object_transform or blender_object_set_origin. No exclusions or context 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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so description adds little beyond noting that it returns a file path. No contradictions, but also no additional behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, all front-loaded. Every sentence adds value: purpose, return value, and usage example. Zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and parameters are well-documented, the description is sufficiently complete for a simple preview render tool. Does not explain render engine or output format, but these are implied by schema and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes all parameters with default values and ranges. Description reinforces with a concrete example (512px, 16 samples), adding practical usage context. Coverage from schema is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Quick render at reduced resolution for preview' and distinguishes from sibling tools like blender_snapshot_viewport by focusing on render preview rather than viewport snapshot. Also mentions returning file path, making purpose specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for quick previews with reduced resolution but does not explicitly state when to use versus alternatives (e.g., export tools or full renders). No exclusions or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the tool is known to be safe. The description adds specific behavioral context by detailing what the summary includes (object counts, materials, etc.), which goes beyond the annotations. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus an example, front-loading the purpose and content. Every sentence adds value: the first states what the tool does, the second gives a practical use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values are documented separately) and comprehensive annotations (readOnly, idempotent, non-destructive), the description is complete enough. It covers what the tool provides (structured summary of scene components) and why you'd use it (to understand existing objects). No further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'format' with a description in the schema itself ('Output format: markdown or json'), and schema description coverage is listed as 0% (likely due to top-level params lack of description). The tool description does not mention the format parameter or its options, leaving the agent without guidance on how to use it. With low schema coverage, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Get a structured summary', which clearly states the action (Get) and resource (current scene). It lists specific components: object counts by type, materials, lights, camera, render settings, and frame range. This distinguishes it from sibling tools like blender_describe_object (which focuses on a single object) and blender_describe_hierarchy (which focuses on parent-child relationships).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example use case: 'Describe the scene to understand what objects exist before making changes.' This implies when to use it (before edits) but does not explicitly state when not to use it or contrast with alternatives like blender_describe_object or blender_object_list. The guidance is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's addition of 'query' and 'returns connection status information' is helpful but not extensive. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, usage guidance, return value. No fluff, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and presence of output schema, the description adequately covers the tool's behavior without needing to detail the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No actual parameters beyond an empty object, so baseline 4 applies. Description does not need to elaborate on parameters since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it queries connection status and statistics with Blender, with explicit mention of diagnosing connection issues and confirming online status. The tool's purpose is unique among siblings, which lack any connection diagnostic 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives clear context for use: to diagnose connection issues and confirm Blender is online. However, it does not explicitly state when not to use it or list alternatives, though the tool's specificity makes it obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, indicating safe non-destructive operation. The description adds substantive behavioral details about what data is returned (topology stats, materials, modifiers, constraints, etc.), providing value beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus a succinct example), front-loads the key purpose and data returned, and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's capabilities comprehensively for a read-only inspection tool, listing all major data categories returned. With an output schema present, the description provides sufficient high-level context for an agent to understand the tool's functionality and usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (name, format) with basic descriptions ('Object name to inspect', 'Output format'). The tool description does not add further semantic meaning to these parameters; the example only demonstrates the 'name' parameter. Given low schema coverage, the description does not fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'deep inspection of a single object' and enumerates specific attributes like topology stats, modifiers, constraints, etc. This distinguishes it from sibling tools like blender_object_get_info (likely lighter) and blender_describe_hierarchy (hierarchy-focused).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an illustrative example ('Inspect 'Cube' to check its polygon count and applied modifiers'), which implies a typical use case. However, it lacks explicit guidance on when not to use this tool compared to alternatives, such as when a quick summary suffices.
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 were provided, so the description carries the full burden. It describes the return value (summary of skills with descriptions, tool counts, status) and explains the concept of skills. For a list tool, this is sufficient context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, each with a distinct purpose: stating the function, explaining the skill concept and next step, and describing the return value. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description is complete. It explains the skill-loading workflow, the tool's role, and what the return value contains. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not elaborate on parameters. Baseline is 4. The description adds value by explaining the tool's function and output, which compensates for the lack of param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (all available skills), and distinguishes this tool from siblings like blender_activate_skill by framing it as a discovery step. The purpose is unambiguous and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Start here to discover what capabilities are available, then use activate_skill to load the tools you need.' This provides clear guidance on the tool's role in the workflow and references a sibling 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?
No annotations are provided, so the description carries full burden. It discloses that the tool removes tools to free up context, indicating a destructive (but reversible) action. However, it does not mention any potential failure modes 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and well-structured. The first sentence states the main purpose, the second provides usage guidance, and the Args section is clear. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is complete. It explains the action, when to use it, and the parameter. The output schema exists, so explaining return values is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'skill_name' has 0% schema description coverage, but the tool description provides a clear explanation: 'Name of the skill to deactivate'. This adds meaning beyond the schema's title 'Skill Name'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Deactivate' and the resource 'a skill', and the purpose of removing tools to free up context. It distinguishes itself from the sibling tool 'blender_activate_skill'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool ('when you no longer need a skill's tools, especially before activating a different skill group'), contrasting with the activation tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, which the description does not contradict. The description adds valuable behavioral context by listing the specific checks performed (world origin, triangle budget, one-object-per-file) and the return value (PASS/FAIL with per-object report), going beyond the 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence purpose followed by a bullet-style list of checks and a clear return value statement. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of an output schema (implied), the description covers the essential context: what it does, when to use it, what it checks, and what it returns. No critical gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite schema description coverage being 0%, the description compensates by outlining the checks (world origin, triangle budget, one-object-per-file) that correspond to parameters like expect_origin, tri_budget, expect_single_object. While it does not explain each parameter in depth, the context provided helps an agent infer parameter usage, earning a high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Re-import an exported FBX and assert game-engine readiness' which identifies the specific verb (re-import and assert) and resource (FBX). It distinguishes itself from sister tool blender_export_fbx, 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Use after blender_export_fbx to self-verify each export instead of post-hoc bulk QA.' This provides clear guidance on when to use the tool and even contrasts with an alternative usage pattern, making it highly instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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