BlenderMCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The tool set has clear thematic grouping (download, generate, status check, import, poll, search, scene operations), but there is notable overlap within groups. For example, generate_hunyuan3d_model, generate_hyper3d_model_via_images, and generate_hyper3d_model_via_text all generate 3D assets via different methods, which could cause confusion. Similarly, import_generated_asset and import_generated_asset_hunyuan serve similar purposes for different backends. Descriptions help differentiate, but the boundaries are not perfectly distinct.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., download_polyhaven_asset, get_scene_info, search_sketchfab_models), with clear and descriptive names. However, there are minor deviations: execute_blender_code uses 'execute' instead of a more specific verb like 'run', and set_texture is a simple verb_noun without a prefix, slightly breaking the pattern. Overall, the naming is highly consistent and predictable.
Tool Count3/5
With 21 tools, the count is on the higher side for a Blender integration server, bordering on heavy. While the tools cover multiple functionalities (asset downloading, 3D generation, status checks, scene management), it might feel overwhelming or redundant, such as having separate status and polling tools for each backend. A more streamlined set could improve usability without losing core capabilities.
Completeness4/5
The tool surface comprehensively covers the domain of Blender asset management and scene manipulation, including downloading from sources (Polyhaven, Sketchfab), generating 3D assets (Hunyuan3D, Hyper3D), checking statuses, importing assets, polling jobs, searching, and scene info. Minor gaps exist, such as no direct tools for modifying objects or scenes beyond applying textures, but agents can work around this using execute_blender_code. Overall, it supports core workflows effectively.
Average 3.4/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 54 of 61 community issues answered or closed in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
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?
No annotations are provided, so the description carries full burden. It states the tool imports an asset and returns success status, but lacks details on permissions, rate limits, error handling, or what 'imported successfully' entails (e.g., scene placement, format compatibility). For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by parameter details and return statement in three clear sentences. It avoids redundancy but could be slightly more structured (e.g., bullet points for parameters).
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 2 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers basic purpose and parameters but lacks behavioral details (e.g., side effects, error cases) and output specifics, which are critical for a mutation tool in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters with brief explanations ('name of the object in scene', 'zip_file_url given in generate model step'), adding some semantics beyond schema titles. However, it doesn't clarify format constraints (e.g., URL validity, name uniqueness) or usage nuances, leaving gaps for 2 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import') and the resource ('asset generated by Hunyuan3D'), distinguishing it from generic import tools like 'import_generated_asset' by specifying the Hunyuan3D source. However, it doesn't explicitly differentiate from all siblings beyond naming the source.
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 context by mentioning 'after the generation task is completed' and referencing 'zip_file_url given in the generate model step,' which suggests it should be used post-generation with a specific URL. However, it lacks explicit when-not-to-use guidance or named alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions optional filtering and that it returns a list with basic information, but doesn't cover pagination, rate limits, authentication needs, error conditions, or what 'basic information' entails. For a search tool with zero annotation coverage, this is insufficient.
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 appropriately brief with three sentences: purpose statement, parameter explanations, and return value note. It's front-loaded with the core function. No wasted words, though it could be slightly more structured with bullet points for parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 2 parameters with 0% schema coverage, the description provides basic purpose and parameter semantics but lacks depth. It doesn't explain the return format, error handling, or usage context relative to siblings. For a search tool in this environment, it's minimally adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'asset_type' values (hdris, textures, models, all) and 'categories' as optional comma-separated list, adding meaningful context beyond the bare schema. However, it doesn't clarify category format or provide examples, leaving some ambiguity.
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 'Search' and resource 'assets on Polyhaven', making the purpose evident. It distinguishes from siblings like 'download_polyhaven_asset' by focusing on search rather than download, but doesn't explicitly differentiate from 'search_sketchfab_models' beyond the platform 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 is provided on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'search_sketchfab_models' or when to use 'get_polyhaven_categories' first for filtering. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a message about feature availability, which is basic behavioral info. However, it lacks details on error handling, performance, or side effects. The note about 'Don't emphasize the key type in the returned message' is vague and doesn't add meaningful context for an AI agent.
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 brief but includes an unclear instruction ('Don't emphasize the key type...') that doesn't add value for tool selection. The first two sentences are front-loaded and clear, but the third sentence is cryptic and doesn't earn its place, reducing overall efficiency.
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 0 parameters, no annotations, and no output schema, the description is minimally adequate. It explains what the tool does and the return type, but lacks details on output format, error cases, or integration with sibling tools. For a simple status check, this is borderline viable but leaves gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, which is efficient. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce confusion about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if Hyper3D Rodin integration is enabled in Blender.' This specifies the verb ('Check'), resource ('Hyper3D Rodin integration'), and context ('in Blender'). However, it doesn't explicitly differentiate from sibling tools like 'get_hunyuan3d_status' or 'get_sketchfab_status' beyond the specific integration name, which slightly limits clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the return message but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't indicate if this should be called before using Hyper3D-related tools or how it differs from other status-checking siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions executing 'arbitrary Python code' and advises step-by-step execution, but fails to disclose critical behavioral traits such as security implications, execution environment details, error handling, permissions required, or potential side effects (e.g., modifying Blender scenes). This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a usage tip and parameter explanation. It avoids unnecessary details, but the parameter section could be more integrated. Overall, it's efficient with little waste.
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 executing arbitrary code in Blender, no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks information on return values, error conditions, execution limits, or safety considerations, which are crucial for an agent to use this tool effectively. The description does not compensate for these gaps adequately.
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 adds minimal meaning beyond the input schema: it defines the 'code' parameter as 'The Python code to execute,' which is straightforward but doesn't elaborate on format, constraints, or examples. With 0% schema description coverage and 1 parameter, the baseline is 4, but the description only partially compensates by stating the parameter's purpose without deeper context, resulting in a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute arbitrary Python code in Blender.' It specifies the verb ('Execute') and resource ('Python code in Blender'), making it distinct from sibling tools which focus on downloading, generating, importing, or querying assets rather than code execution. However, it doesn't explicitly differentiate from hypothetical similar code-execution tools, though none exist among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: 'Make sure to do it step-by-step by breaking it into smaller chunks.' This suggests a best practice for using the tool, but it doesn't explicitly state when to use this tool versus alternatives (e.g., for code execution vs. asset manipulation) or list any exclusions. No clear alternatives or context for tool selection are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Get detailed information') but doesn't describe what information is returned, format of response, error conditions, or any performance characteristics. The description is minimal beyond stating the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with zero wasted words. It uses a clear two-sentence structure: first stating the purpose, then documenting the single parameter. Every sentence earns its place and the information is front-loaded appropriately.
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 no annotations, no output schema, and 0% schema description coverage, the description is insufficiently complete. While it states the basic purpose and documents the parameter, it doesn't describe what 'detailed information' includes, the response format, or any behavioral aspects needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the single parameter 'object_name' with a clear explanation ('The name of the object to get information about'). With 0% schema description coverage and only 1 parameter, this provides good semantic context beyond the bare schema, though it doesn't elaborate on naming conventions or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get detailed information') and resource ('a specific object in the Blender scene'). It distinguishes from some siblings like 'get_scene_info' (which likely gets scene-level info) but doesn't explicitly differentiate from all possible read operations.
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. It doesn't mention when this tool is appropriate compared to 'get_scene_info' or other information-retrieval tools, nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Get detailed information') but lacks critical details: what format the information is returned in, whether it's read-only (implied but not explicit), potential errors if no scene exists, or performance considerations. This leaves significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It's front-loaded and wastes no words, making it highly concise and well-structured for quick understanding.
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 (a read operation with no parameters but no output schema), the description is incomplete. It doesn't specify what 'detailed information' includes (e.g., scene properties, objects, settings) or the return format, which is critical since there's no output schema. With no annotations and missing output details, it fails to provide enough context for reliable use.
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 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately avoids redundancy. A baseline of 4 is given since no parameters exist, and the description doesn't add unnecessary details.
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 the current Blender scene'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_object_info' or 'get_viewport_screenshot', which prevents a perfect score.
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. There's no mention of prerequisites, context (e.g., when a scene is loaded), or comparisons to siblings like 'get_object_info' for object-specific details, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions access rights and downloadability, which adds some behavioral context, but it doesn't disclose critical traits like whether this is a read-only or destructive operation, potential rate limits, error handling, or what 'import' entails (e.g., file format, storage location). This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core action. The sentences are efficient, but the second sentence about returns could be integrated more smoothly, and the prerequisites are listed without unnecessary elaboration, making it mostly concise with minor room for improvement.
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 a download/import operation, no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on output format beyond a success/failure message, error conditions, what 'import' means in practice, and how it interacts with sibling tools. This makes it inadequate for full agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It provides the parameter 'uid' with a clear explanation ('The unique identifier of the Sketchfab model'), adding essential meaning beyond the bare schema. However, it doesn't specify the format or constraints of the UID (e.g., length, pattern), which could be helpful, so it's not a perfect score.
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 ('Download and import') and the resource ('a Sketchfab model by its UID'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'search_sketchfab_models' or 'import_generated_asset', which could handle similar resources or steps, so it falls short of a perfect score.
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 by mentioning prerequisites ('The model must be downloadable and you must have proper access rights'), but it doesn't explicitly state when to use this tool versus alternatives like 'search_sketchfab_models' for finding models or 'import_generated_asset' for importing. This provides some context but lacks clear differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's behavior: it returns a message indicating availability of Hunyuan3D features. However, it doesn't mention error conditions, performance characteristics, or whether this is a read-only operation (though implied by 'check'). The note about 'Don't emphasize the key type...' adds some behavioral context but is somewhat cryptic.
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 reasonably concise but could be more front-loaded. The first sentence clearly states the purpose, but the second sentence partially repeats it. The third sentence about 'Don't emphasize the key type...' is somewhat vague and doesn't add clear value for tool selection.
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 (0 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It explains what the tool does but lacks context about when to use it, what the return message format might be, or how it relates to other Hunyuan3D tools like 'generate_hunyuan3d_model' or 'import_generated_asset_hunyuan'.
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 0 parameters, and schema description coverage is 100%. The description doesn't need to explain parameters, so it appropriately focuses on the tool's function. No parameter information is missing or needed 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 the tool's purpose: 'Check if Hunyuan3D integration is enabled in Blender' (specific verb+resource). It distinguishes from siblings like 'get_hyper3d_status' by specifying the Hunyuan3D integration. However, it doesn't fully differentiate from 'get_polyhaven_status' or 'get_sketchfab_status' beyond the target resource 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 is provided. The description doesn't mention prerequisites, context for checking integration status, or when to choose this over other status-checking siblings like 'get_hyper3d_status'. Usage is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('Get a list'), which implies it's non-destructive, but fails to mention critical details like rate limits, authentication needs, error handling, or the format of the returned list. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a concise parameter explanation. Every sentence earns its place by adding value, with no redundant or verbose language, making it efficiently structured and easy to parse.
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 low complexity (1 parameter, no output schema, no annotations), the description is adequate as a minimum viable explanation. It covers the purpose and parameter semantics but lacks details on behavioral traits and usage guidelines, which are needed for full contextual understanding despite the simple schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'asset_type' by listing its possible values (hdris, textures, models, all), which is not covered in the input schema (0% schema description coverage). This compensates well for the schema's lack of detail, providing clear semantics beyond the basic property definition.
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 a list of') and resource ('categories for a specific asset type on Polyhaven'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'search_polyhaven_assets', which might also involve categories, leaving room for ambiguity in distinguishing its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'search_polyhaven_assets' which might retrieve assets within categories. It mentions the asset_type parameter but offers no context on prerequisites, exclusions, or typical use cases, relying solely on the tool name for implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool returns a message about feature availability, which hints at a read-only operation, but doesn't clarify if it requires specific permissions, has side effects, or details the response format (e.g., structured data vs. plain text). For a tool with zero annotation coverage, this is insufficient to fully inform the agent about its 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 and front-loaded, consisting of two clear sentences that directly address the tool's function and output. Every word serves a purpose with no redundancy or fluff, making it easy for an agent to parse quickly and efficiently.
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 (0 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains what the tool does and what it returns, but without annotations or an output schema, it lacks details on behavioral traits (e.g., error handling) and the exact format of the return message. This makes it minimally viable but not fully comprehensive for agent use.
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 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately avoids mentioning any. A baseline of 4 is applied as per the rules for zero-parameter tools, as the description doesn't introduce unnecessary complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if PolyHaven integration is enabled in Blender.' It specifies the verb ('Check') and resource ('PolyHaven integration in Blender'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_hunyuan3d_status' or 'get_sketchfab_status' beyond the PolyHaven focus, which prevents a perfect score.
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. It doesn't mention prerequisites (e.g., whether Blender must be running), compare it to similar status-checking siblings, or indicate scenarios where it's appropriate. This lack of contextual usage information leaves the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'Returns a formatted list of matching models,' which gives some output information, but it lacks details on rate limits, authentication needs, error handling, pagination, or what 'formatted' entails. For a search tool with no annotation coverage, this is insufficient.
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 appropriately sized and front-loaded. The first sentence states the purpose clearly, followed by a bulleted list of parameters with concise explanations. There is no wasted text, and every sentence earns its place by adding necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description is partially complete. It covers parameters well but lacks behavioral details like rate limits or error handling. Without an output schema, it should explain return values more thoroughly than just 'formatted list.' It's adequate as a minimum viable description but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for all four parameters: 'query' as 'Text to search for,' 'categories' as 'Optional comma-separated list of categories,' 'count' as 'Maximum number of results to return (default 20),' and 'downloadable' as 'Whether to include only downloadable models (default True).' This provides clear context beyond the bare schema, though it doesn't explain category values or result formatting details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for models on Sketchfab with optional filtering.' It specifies the verb ('search'), resource ('models on Sketchfab'), and scope ('with optional filtering'). However, it doesn't explicitly distinguish this tool from its sibling 'search_polyhaven_assets' beyond the platform name, which is why it doesn't reach a score of 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_polyhaven_assets' or 'download_sketchfab_model', nor does it specify prerequisites, context, or exclusions. The only implied usage is for searching Sketchfab models, but this is redundant with the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the operation is asynchronous (returns job_id, status changes to 'DONE'), mentions failure cases, and notes built-in materials. However, it lacks details on permissions, rate limits, timeouts, or what 'import into Blender' entails operationally. The behavioral context is partial but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core functionality. The parameter and return sections are structured but slightly verbose (e.g., repeating 'When successful...'). Most sentences earn their place, though some redundancy exists in the returns explanation.
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 no annotations, 0% schema coverage, no output schema, and moderate complexity (asynchronous 3D generation), the description is partially complete. It covers purpose, parameters, and return behavior but lacks details on error handling, Blender integration specifics, and sibling differentiation. It's adequate but has clear gaps for a tool with this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics: text_prompt is described as 'a short description of the desired model in English/Chinese,' and input_image_url as 'local or remote url' that 'Accepts None if only using text prompt.' This clarifies optionality and format beyond the bare schema. However, it doesn't cover constraints like image size or prompt length.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate 3D asset using Hunyuan3D' and 'import the asset into Blender.' It specifies the input modalities (text, image, or both) and mentions built-in materials. However, it doesn't explicitly differentiate from siblings like 'generate_hyper3d_model_via_images' or 'import_generated_asset_hunyuan' beyond the Hunyuan3D reference.
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. With siblings like 'generate_hyper3d_model_via_text', 'generate_hyper3d_model_via_images', and 'import_generated_asset_hunyuan', there's no indication of comparative use cases, prerequisites, or exclusions. Usage is implied by the description but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the basic behavior: checking integration status and returning a message. However, it lacks details such as error handling (e.g., what happens if Blender isn't accessible), performance characteristics, or whether this is a read-only operation (implied but not stated). The description doesn't contradict annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: two sentences that directly state the action and the return value. Every word earns its place, with no redundancy or fluff. It's front-loaded with the core purpose, making it easy to scan.
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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return type but lacks context like error cases, integration specifics, or how the result informs other tools (e.g., 'download_sketchfab_model'). For a simple status check, it's passable but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate. Baseline is 4 for zero parameters, as it avoids unnecessary repetition and focuses on the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if Sketchfab integration is enabled in Blender.' It specifies the verb ('Check') and resource ('Sketchfab integration in Blender'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_hunyuan3d_status' or 'get_hyper3d_status', which have similar checking purposes for other integrations.
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. It doesn't mention prerequisites (e.g., whether Blender must be running), exclusions, or related tools like 'download_sketchfab_model' that might depend on this status check. Usage is implied by the purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool generates and imports a 3D asset with built-in materials and normalized size, which are useful behavioral traits. However, it lacks details on permissions, rate limits, error handling, or what 'success or failure' entails, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. Sentences like 'The 3D asset has built-in materials' and 'The generated model has a normalized size' add value without redundancy. The parameter section is clear but could be more integrated. Minor improvements in flow could achieve a 5.
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 no annotations, no output schema, and 0% schema coverage, the description provides basic context but has gaps. It explains what the tool does and parameters, but lacks details on return values (beyond 'success or failure'), error cases, or integration with sibling tools. For a tool with 2 parameters and mutation behavior, this is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'text_prompt' is 'A short description of the desired model in **English**' and 'bbox_condition' controls the ratio between [Length, Width, Height]. This clarifies parameter purposes beyond the schema's basic titles. However, it doesn't detail format constraints (e.g., array length validation) or provide examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate 3D asset using Hyper3D by giving description of the desired asset, and import the asset into Blender.' It specifies the verb (generate and import), resource (3D asset), and technology (Hyper3D). However, it doesn't explicitly differentiate from sibling tools like 'generate_hunyuan3d_model' or 'generate_hyper3d_model_via_images', which would require 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 implies usage by mentioning 'by giving description of the desired asset' and notes that 're-scaling after generation can be useful,' but it doesn't provide explicit guidance on when to use this tool versus alternatives like sibling tools (e.g., 'generate_hunyuan3d_model_via_images' for image-based generation). No exclusions or clear alternatives are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions what the tool does but doesn't describe important behavioral aspects: whether it requires specific Blender state, what happens if viewport is empty, performance characteristics, or error conditions. The description is functional but lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by clear parameter documentation. Every sentence earns its place with no wasted words, and the structure (purpose → parameters → return) is logical and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no annotations and no output schema, the description covers the basic functionality adequately but lacks completeness. It doesn't explain the return format ('Image' is vague), doesn't mention what happens if the viewport isn't available, and provides minimal behavioral context. It meets minimum viability but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only one parameter, the description adds significant value by explaining the parameter's purpose ('Maximum size in pixels for the largest dimension') and providing the default value (800). This compensates well for the lack of schema documentation, though it doesn't specify constraints like minimum/maximum values.
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 specific action ('Capture a screenshot') and target resource ('current Blender 3D viewport'), distinguishing it from all sibling tools which involve downloading assets, generating models, getting statuses, or importing assets rather than capturing visual output from the viewport.
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, prerequisites, or context. It doesn't mention if this should be used instead of other screenshot methods or in what workflow scenarios it's appropriate, leaving the agent with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool imports assets and returns success status, but lacks details on permissions, error handling, or side effects. It adds some context about modes but doesn't fully compensate for missing annotation coverage.
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?
Front-loaded with the main purpose, followed by parameter explanations and a usage rule. Sentences are efficient, though the parameter list could be integrated more smoothly. Overall, it's appropriately sized with minimal waste.
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?
No annotations or output schema exist, and the description covers parameter semantics well but lacks behavioral details like error cases or return format. Given the complexity (3 parameters, no structured guidance), it's adequate but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the purpose of each parameter (name for object in scene, task_uuid for MAIN_SITE mode, request_id for FAL_AI mode) and the exclusive choice rule, adding significant value beyond the bare 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 'Import' and the resource 'asset generated by Hyper3D Rodin', specifying it's for assets after generation tasks. It distinguishes from sibling 'import_generated_asset_hunyuan' by specifying Hyper3D Rodin, though not explicitly contrasting them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use after generation tasks are completed, and specifies parameter selection based on Hyper3D Rodin Mode (MAIN_SITE vs FAL_AI). However, it doesn't explicitly state when NOT to use it or compare with alternatives like 'import_generated_asset_hunyuan'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it's a polling API, returns statuses like 'DONE' or 'RUN', and includes the ResultFile3Ds field with a ZIP file path when done. However, it lacks details on error handling, rate limits, or authentication needs, which are important for a polling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but has some redundancy. Sentences like 'Returns the generation task status...' and 'When the status is "DONE", the response includes...' repeat information about the ResultFile3Ds field. It could be more front-loaded and streamlined, but overall, it conveys necessary details without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a polling tool with no annotations and no output schema, the description is moderately complete. It explains the purpose, parameter, return values, and behavioral context (polling nature). However, it lacks details on error states, response formats beyond statuses, or how to handle intermediate states, which could be important for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds meaningful semantics: 'job_id: The job_id given in the generate model step.' This clarifies the parameter's purpose and origin, which is valuable beyond the schema's basic type information. Since there's only one parameter, this is sufficient for good understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if the Hunyuan3D generation task is completed.' It specifies the verb ('check') and resource ('Hunyuan3D generation task'), making the intent unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_hunyuan3d_status' or 'poll_rodin_job_status', which appear to serve similar polling functions for different job types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'This is a polling API, so only proceed if the status are finally determined ("DONE" or some failed state).' This indicates when to use it—for checking final statuses—but doesn't explicitly state when not to use it or name alternatives like 'get_hunyuan3d_status' (a sibling tool), which might offer different functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks critical behavioral details. It doesn't disclose whether this downloads files locally, imports them into an active Blender session, requires authentication, has rate limits, or what happens on failure. The mention of 'Returns a message' is vague about error handling or success confirmation.
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 efficiently structured with a clear purpose statement followed by a bulleted parameter list. Every sentence adds value: the first establishes the tool's core function, and the parameter explanations are necessary given the lack of schema descriptions. No redundant or verbose language.
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 4-parameter tool with no annotations and no output schema, the description does a decent job explaining parameters but lacks completeness in behavioral aspects. It doesn't cover what the tool returns beyond 'a message', error conditions, or integration details with Blender. Given the complexity of downloading and importing assets, more context on the operation's flow would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining all 4 parameters with examples and context. It clarifies that 'file_format' is optional and provides format examples per asset type (e.g., 'hdr, exr for HDRIs'), adding meaningful semantics beyond the bare schema. However, it doesn't specify valid values for 'asset_type' or 'resolution' beyond examples.
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 specific action ('Download and import'), target resource ('Polyhaven asset'), and destination ('into Blender'). It distinguishes from siblings like 'search_polyhaven_assets' (which finds assets) and 'import_generated_asset' (which imports from other sources).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'into Blender' and listing asset types, suggesting this is for Blender users working with Polyhaven assets. However, it doesn't explicitly state when to use this versus alternatives like 'download_sketchfab_model' or 'import_generated_asset', nor does it mention prerequisites like having Blender running.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the texture must be downloaded first (a prerequisite) and describes the return value. However, it doesn't disclose critical behavioral traits like whether this operation is destructive (modifies the object permanently), what permissions are needed, error conditions, or rate limits. For a mutation tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. It opens with a clear purpose statement, then provides a bulleted list of parameters with explanations, and ends with return value information. Every sentence earns its place, with zero wasted words, making it easy to scan and understand quickly.
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 (a mutation operation with 2 parameters), no annotations, and no output schema, the description does an adequate job but has clear gaps. It covers the basic purpose, parameters, and return value, but lacks details on behavioral aspects like destructiveness, error handling, or integration with sibling tools. For a tool that modifies objects, more context would be beneficial.
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 schema description coverage is 0%, so the description must fully compensate. It explicitly lists both parameters ('object_name' and 'texture_id') with clear semantic explanations: 'Name of the object to apply the texture to' and 'ID of the Polyhaven texture to apply (must be downloaded first)'. This adds essential meaning beyond the bare schema, fully documenting parameter purposes and constraints.
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 specific action ('Apply'), resource ('previously downloaded Polyhaven texture'), and target ('to an object'). It distinguishes from siblings like 'download_polyhaven_asset' (which downloads textures) and 'get_object_info' (which retrieves information). The verb+resource combination is precise 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about prerequisites ('must be downloaded first'), which implicitly guides when to use this tool versus alternatives. However, it doesn't explicitly state when NOT to use it or name specific alternative tools for similar operations. The guidance is helpful but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it's a polling API that should only proceed when status is finally determined, it returns status lists or single status depending on mode, and it explains what different status values mean (Done, Failed, COMPLETED, IN_PROGRESS, etc.). It doesn't cover rate limits, authentication needs, or error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized but could be more front-loaded. The first sentence states the purpose clearly, but the detailed mode-specific information follows in a somewhat repetitive structure. Some redundancy exists in explaining polling behavior twice for different modes. Every sentence adds value, but organization could be more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two operational modes with different parameters and return formats), no annotations, and no output schema, the description does a good job covering essential information. It explains what the tool does, when to use it, parameter meanings, return value interpretation, and polling behavior. It doesn't specify exact return formats or error cases, but provides sufficient context for correct usage.
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?
With 0% schema description coverage, the description fully compensates by explaining both parameters in detail: subscription_key is for MAIN_SITE mode and comes from the generate model step, request_id is for FAL_AI mode and also comes from the generate model step. It clarifies the exclusive relationship between these parameters based on the mode being used.
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 checks if a Hyper3D Rodin generation task is completed, specifying the verb 'check' and resource 'task status'. It distinguishes from siblings like 'get_hyper3d_status' by focusing on Rodin mode specifically, though it doesn't explicitly contrast with 'poll_hunyuan_job_status' which has a similar polling function for a different service.
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 clear context for when to use this tool: after initiating a generation task in Hyper3D Rodin mode, using parameters from that step. It distinguishes between MAIN_SITE and FAL_AI modes with specific parameter requirements. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'get_hyper3d_status' for non-Rodin tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool generates a 3D asset with built-in materials, imports it into Blender, normalizes the model size (suggesting re-scaling may be needed), and returns a success/failure message. It also clarifies the mode-dependent parameter requirements. However, it lacks details on error conditions, processing time, or Blender integration specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized, with a clear purpose statement followed by parameter details. Every sentence adds value, such as explaining material properties and normalization. However, it could be slightly more front-loaded by moving the parameter section after the purpose, and minor wording like 'wanted asset' could be tightened to 'desired asset' for better clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3D generation and import), no annotations, 0% schema coverage, and no output schema, the description does a strong job. It covers purpose, parameters with semantics, behavioral traits (materials, normalization, return message), and mode dependencies. It could improve by detailing output format beyond success/failure or error handling, but overall it provides sufficient context for effective tool use.
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?
Schema description coverage is 0%, so the description must compensate fully. It provides essential semantics: input_image_paths requires absolute paths and must be a list even for one image, input_image_urls requires URLs similarly wrapped, and bbox_condition is optional with a specific format (list of 3 ints controlling Length, Width, Height ratio). It also explains the exclusive choice between input_image_paths and input_image_urls based on Hyper3D Rodin mode, adding critical usage context not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate 3D asset using Hyper3D by giving images of the wanted asset, and import the generated asset into Blender.' It specifies the verb (generate and import), resource (3D asset via Hyper3D), and distinguishes from siblings like generate_hyper3d_model_via_text (images vs. text) and import_generated_asset (which lacks generation).
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 clear context for usage: it specifies that input_image_paths is required for MAIN_SITE mode and input_image_urls for FAL_AI mode, and that only one of these should be given. However, it does not explicitly state when to use this tool over alternatives like generate_hunyuan3d_model or download_polyhaven_asset, nor does it mention prerequisites or exclusions beyond the mode dependency.
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/ahujasid/blender-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ahujasid/blender-mcp)

Score Badge

Copy to your README.md:

[![blender-mcp MCP server](https://glama.ai/mcp/servers/ahujasid/blender-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ahujasid/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/ahujasid/blender-mcp'

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