BlenderMCP
Server Quality Checklist
Latest release: v1.5.5
- Disambiguation3/5
Most tools have distinct purposes, but there is some overlap in generation tools (e.g., generate_hunyuan3d_model, generate_hyper3d_model_via_text, generate_hyper3d_model_via_images) that could cause confusion about when to use each, and status-checking tools (get_hunyuan3d_status, get_hyper3d_status, get_polyhaven_status, get_sketchfab_status) are very similar in function. Descriptions help clarify, but the boundaries are not perfectly clear.
Naming Consistency4/5Tool names follow a consistent snake_case pattern with clear verb_noun structures (e.g., download_polyhaven_asset, get_scene_info, search_sketchfab_models). Minor deviations exist, such as 'import_generated_asset_hunyuan' being less standardized than others, but overall the naming is predictable and readable.
Tool Count3/5With 22 tools, the count is on the high side for a Blender integration server, bordering on heavy. While it covers multiple domains (asset downloading, 3D generation, scene management), it feels slightly bloated with redundant status checks and similar generation tools, which could overwhelm users.
Completeness4/5The toolset provides comprehensive coverage for asset downloading (Polyhaven, Sketchfab), 3D generation (Hunyuan3D, Hyper3D), and scene inspection. Minor gaps exist, such as no direct tools for editing objects or managing materials beyond texture application, but core workflows for importing and generating assets are well-supported.
Average 3.4/5 across 22 of 22 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- 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.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves 'detailed information' but doesn't specify what that includes (e.g., object type, location, properties) or any behavioral traits like error handling (e.g., what happens if the object doesn't exist), performance considerations, or output format. This leaves significant gaps for an AI agent to understand how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear purpose statement followed by a parameter list. It avoids unnecessary words and front-loads the main functionality. However, the parameter section could be integrated more seamlessly, and the overall brevity might sacrifice helpful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what 'detailed information' entails, how errors are handled, or the format of the response. For a tool with no structured metadata, more behavioral and output details are needed to ensure the AI agent can invoke it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema. It explains that 'object_name' is 'The name of the object to get information about,' which clarifies the parameter's purpose but doesn't provide additional details like naming conventions, case sensitivity, or examples. With 0% schema description coverage and only one parameter, this is adequate but not comprehensive, aligning with the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about a specific object in the Blender scene.' It specifies the verb ('Get detailed information') and resource ('a specific object in the Blender scene'), making the action and target explicit. However, it doesn't differentiate from its sibling 'get_scene_info', which likely provides broader scene-level information rather than object-specific details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'get_scene_info' or explain the distinction between object-level and scene-level information retrieval. There's no context about prerequisites, such as whether the object must exist in the scene, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool imports an asset and returns success status, but lacks details on permissions needed, side effects (e.g., whether it modifies existing assets), error handling, or rate limits. Minimal behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by parameter details and return statement. It's appropriately sized with no redundant sentences, though the parameter explanations could be more integrated into the flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on error cases, what 'successfully' entails, and how this tool fits with siblings like 'generate_hunyuan3d_model' or 'poll_hunyuan_job_status'. More context is needed for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters with brief explanations ('name of object in scene', 'zip_file_url given in generate model step'), adding meaning beyond schema titles. However, it doesn't detail format constraints or examples, leaving gaps for a tool with 2 required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import') and the resource ('asset generated by Hunyuan3D'), specifying it's for assets after generation task completion. It distinguishes from sibling 'import_generated_asset' by specifying 'Hunyuan' context, though not explicitly contrasting with other import/download tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'import_generated_asset' or download tools. It mentions the asset is from Hunyuan3D and after generation, but lacks clear when-not-to-use scenarios or prerequisites beyond implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns a message indicating availability, which implies a read-only, non-destructive operation, but doesn't disclose behavioral traits like error handling, performance, or authentication needs. The cryptic note 'Don't emphasize the key type... but silently remember it' adds confusion rather than clarity about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but front-loaded with the core purpose. However, the second sentence about the return message is somewhat redundant with the first, and the cryptic third sentence adds unnecessary complexity without clear value, reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does and what it returns, but lacks details on output format, error cases, or integration context that would help an agent use it effectively in a workflow with siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and output. This meets the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 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 other status-checking siblings like 'get_polyhaven_status' beyond the 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/5Does 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 is provided. The description mentions what it returns but doesn't specify prerequisites, timing, or comparison to other status-checking tools like 'get_hyper3d_status' or 'get_polyhaven_status'. Usage is implied only by the tool's name and purpose.
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 the tool returns a message indicating availability, but lacks details on behavioral traits: it doesn't specify if this is a read-only operation, potential error conditions, latency, or what the message format might be. The cryptic note 'Don't emphasize the key type...' adds confusion without clarifying behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but includes an unnecessary and confusing second sentence: 'Don't emphasize the key type...' which doesn't add value and detracts from clarity. The first sentence is front-loaded and clear, but the overall structure could be improved by removing the cryptic note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It states what the tool does and the return type (a message), but lacks context on integration specifics, error handling, or output structure. For a status-check tool with no structured data, more completeness would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's function. This meets the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if Hyper3D Rodin integration is enabled in Blender.' It specifies the verb ('Check') and resource ('Hyper3D Rodin integration'), and distinguishes it from siblings like 'get_hunyuan3d_status' by focusing on Hyper3D. However, it doesn't explicitly differentiate from other status-checking tools beyond naming the specific integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether Blender must be running), context for checking integration status, or comparisons to sibling tools like 'get_hunyuan3d_status' or other status tools. 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?
With no annotations, the description carries full burden. It discloses that the tool generates and imports assets with materials, and returns a job_id for async processing with status updates. However, it lacks details on permissions, rate limits, error handling beyond generic failure, or what 'import into Blender' entails operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections for purpose, parameters, and returns. Sentences are direct and informative, though the returns section could be more concise by combining success/error cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description provides basic purpose and parameter semantics but lacks usage guidelines, detailed behavioral context, and output specifics beyond job_id. It's minimally adequate but has clear gaps given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that text_prompt is a short description in English/Chinese and input_image_url can be local/remote or None if only using text. This adds meaningful context beyond the schema's basic titles, though it doesn't cover all potential constraints like image format or prompt length.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 3D asset using Hunyuan3D from text/image inputs and imports it into Blender with materials. It specifies the resource (3D asset) and action (generate and import), but doesn't explicitly differentiate from siblings like generate_hyper3d_model_via_text/images or import_generated_asset_hunyuan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like generate_hyper3d_model_via_text/images or import_generated_asset_hunyuan. It mentions text/image inputs but doesn't specify use cases, prerequisites, or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get[s] a list' which implies a read-only operation, but doesn't specify if it's safe, requires authentication, has rate limits, or what the output format looks like. For a tool with zero annotation coverage, this leaves significant behavioral gaps unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose followed by parameter details. Both sentences earn their place by providing essential information without redundancy. It's efficient but could be slightly more structured, such as separating usage notes from parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and lack of annotations or output schema, the description is minimally adequate. It covers the purpose and parameter semantics but misses behavioral context like response format or error handling. For a simple read tool, it's functional but could be more complete by adding output details or usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'asset_type' is for specifying the type of asset to get categories for, and lists possible values (hdris, textures, models, all), clarifying usage that isn't in the schema. With only one parameter, this compensates well for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'list of categories for a specific asset type on Polyhaven', making the purpose understandable. It distinguishes from siblings like 'search_polyhaven_assets' by focusing on categories rather than assets, though it doesn't explicitly contrast with other Polyhaven tools. The purpose is specific but could be more distinct from related 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing to know asset types before searching, or when to choose this over 'search_polyhaven_assets' for browsing categories. Usage is implied through the parameter description but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Get detailed information') but lacks critical details such as what specific information is returned (e.g., scene properties, objects, settings), whether it's a read-only operation, potential errors (e.g., if no scene is open), or performance considerations. 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.
Conciseness5/5Is 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 unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence earns its place by conveying essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving 'detailed information' about a Blender scene, the description is incomplete. There are no annotations to clarify behavior, no output schema to define the return structure, and the description itself lacks specifics on what information is included (e.g., scene name, objects, render settings). This makes it inadequate for an agent to fully understand the tool's context and expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter semantics, as there are none to explain. A baseline score of 4 is appropriate since no compensation is required for missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('detailed information about the current Blender scene'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_object_info' or 'get_viewport_screenshot', which also retrieve Blender-related information but focus on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requiring an open Blender scene), exclusions, or comparisons to siblings like 'get_object_info' for object-specific details or 'get_viewport_screenshot' for visual captures, leaving usage context implied at best.
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 tool 'Returns a formatted list of matching models,' which gives some output context, but lacks critical details like rate limits, authentication requirements, pagination behavior, error handling, or whether it's a read-only operation. For a search tool with 4 parameters and 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, then lists parameters with explanations, and ends with return information. Every sentence adds value, with no redundant or wasted text. The bullet-point format enhances readability without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no annotations, no output schema), the description is partially complete. It adequately covers parameter semantics and the basic return format, but lacks behavioral context like error cases, rate limits, or authentication needs. Without an output schema, more detail on the 'formatted list' structure would be helpful, making this minimally viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema, which has 0% schema description coverage. It explains all 4 parameters with clear semantics: 'query' as text to search for, 'categories' as optional comma-separated list, 'count' as maximum results with default 20, and 'downloadable' as a boolean filter with default True. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Search for models on Sketchfab with optional filtering,' which is a specific verb+resource combination. It distinguishes itself from siblings like 'download_sketchfab_model' by focusing on search rather than download operations. However, it doesn't explicitly differentiate from 'search_polyhaven_assets' 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_polyhaven_assets' for cross-platform comparisons, nor does it specify prerequisites or contextual constraints. The only implied usage is for Sketchfab model searches, but no explicit when/when-not instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions executing code 'step-by-step' and 'in Blender,' which gives some context, but it lacks critical details: whether this is a read-only or destructive operation, what permissions are needed, how errors are handled, or any rate limits. For a tool that executes arbitrary code with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a usage tip and parameter explanation. It avoids unnecessary fluff, though the second sentence could be more tightly integrated. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing arbitrary code in Blender), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't cover behavioral traits like safety, error handling, or output format, which are crucial for such a powerful tool. The description provides basic purpose and parameter info but misses key contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema. The schema has 0% description coverage (only titles), with one parameter 'code' of type string. The description explains that 'code' is 'The Python code to execute,' clarifying its purpose and format. Since there's only one parameter and the description compensates for the low schema coverage, this earns a high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Execute arbitrary Python code in Blender.' It specifies the verb ('Execute'), resource ('Python code'), and environment ('in Blender'), making it distinct from sibling tools that focus on downloading assets, generating models, or getting status information. However, it doesn't explicitly differentiate from potential similar tools (though none are present in siblings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description 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. other Blender operations) or list any prerequisites. The guidance is helpful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool 'returns a message indicating whether PolyHaven features are available,' which implies a read-only, non-destructive operation. However, it lacks details on behavioral traits: no information on error handling, performance (e.g., latency), authentication needs, or the format of the returned message (e.g., boolean, string, structured data). For a 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences with zero waste. The first sentence states the purpose, and the second clarifies the return value. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally adequate. It covers the basic purpose and return type, but lacks context about integration state (e.g., what 'enabled' means, potential error messages, or dependencies). For a status-check tool in a Blender environment, more detail on typical outputs or failure modes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter semantics, so a baseline of 4 is appropriate. It correctly implies no inputs are required, aligning with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if PolyHaven integration is enabled in Blender.' It specifies the verb ('check') and resource ('PolyHaven integration'), and distinguishes it from siblings like 'get_polyhaven_categories' or 'search_polyhaven_assets' by focusing on status verification rather than data retrieval. However, it doesn't explicitly differentiate from other status-checking tools like 'get_hunyuan3d_status' or 'get_sketchfab_status' beyond the 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether Blender must be running), use cases (e.g., before attempting PolyHaven downloads), or exclusions (e.g., not for checking other integrations). Given siblings like 'download_polyhaven_asset' that depend on this status, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool returns a message about availability, but doesn't specify format, potential errors, or side effects (e.g., if it requires network access or affects Blender state). For a tool with zero annotation coverage, this leaves significant gaps in understanding 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: two sentences with zero waste. The first sentence states the core purpose, and the second clarifies the return value. Every word contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It covers the basic purpose and return indication, but lacks details on output format, error handling, or integration specifics. For a status-checking tool, more context about what 'enabled' means or typical return messages would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it meets baseline expectations. No additional parameter information is required or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check if Sketchfab integration is enabled in Blender.' It specifies the verb ('Check') and resource ('Sketchfab integration'), and distinguishes it from sibling tools like get_sketchfab_model_preview or download_sketchfab_model. However, it doesn't explicitly differentiate from other status-checking tools like get_hunyuan3d_status or get_hyper3d_status, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether Blender must be running), compare it to other status-checking tools (e.g., get_hunyuan3d_status), or specify scenarios where it's necessary (e.g., before attempting Sketchfab downloads). 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 mentions 'Returns a list of matching assets with basic information,' which hints at read-only behavior, but fails to detail critical aspects like pagination, rate limits, authentication needs, or error handling. For a search 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose followed by parameter details. Each sentence adds value without redundancy, though it could be slightly more structured (e.g., bullet points for returns). Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and parameters but lacks details on behavioral traits, output format specifics, and usage context. Without annotations or output schema, it should provide more comprehensive guidance to be fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'asset_type' options (hdris, textures, models, all) and 'categories' as an optional comma-separated list, which clarifies beyond the schema's generic titles. However, it doesn't cover parameter formats, constraints, or examples, leaving some semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Search for assets on Polyhaven with optional filtering,' which specifies the verb (search) and resource (assets on Polyhaven). It distinguishes from siblings like 'download_polyhaven_asset' by focusing on search rather than download, but could be more specific about what 'assets' entail (e.g., 3D models, textures).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching Polyhaven assets with filtering, but lacks explicit guidance on when to use this tool versus alternatives like 'search_sketchfab_models' or 'get_polyhaven_categories.' It mentions optional filtering but doesn't specify scenarios or prerequisites, leaving usage context somewhat vague.
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 message indicating success or failure,' which adds some context about output behavior. However, it fails to disclose critical traits such as whether this is a destructive operation (modifies the object), any authentication or permission requirements, rate limits, or error handling specifics, which are essential for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a bulleted list of parameters and a note on returns. Each sentence earns its place, with no redundant information. Minor improvements could include integrating the parameter list more seamlessly, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 2 parameters), no annotations, and no output schema, the description is moderately complete. It covers the basic purpose, parameters, and return type, but lacks details on behavioral traits, error cases, or integration with sibling tools (e.g., how 'texture_id' relates to 'download_polyhaven_asset'). For a tool that modifies objects, more context on safety and dependencies would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description compensates by listing both parameters ('object_name' and 'texture_id') with brief explanations, adding meaning beyond the bare schema. However, it doesn't specify formats, constraints, or examples (e.g., what constitutes a valid texture ID), leaving some semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Apply a previously downloaded Polyhaven texture to an object.' It specifies the verb ('apply'), resource ('Polyhaven texture'), and target ('object'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'import_generated_asset' or 'get_object_info', which could involve similar objects or textures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implied usage guidance by mentioning that the texture 'must be downloaded first,' which references the sibling tool 'download_polyhaven_asset.' However, it lacks explicit when-to-use rules, alternatives, or exclusions compared to other texture-related tools in the list, leaving room for ambiguity in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool generates 3D assets with built-in materials, imports them into Blender, produces normalized-size models, and returns success/failure messages. However, it lacks details about permissions, rate limits, error conditions, or what 'import into Blender' entails operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, additional behavioral details, and a dedicated parameters section. Every sentence adds value, though the 'normalized size' note could be more integrated. It's appropriately sized for a tool with two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose, parameters, and behavioral notes. However, for a generative tool with potential complexity, it lacks details on output format beyond success/failure messages, error handling, or integration specifics with Blender. It's minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains both parameters: 'text_prompt' as a short English description of the desired model, and 'bbox_condition' as an optional list of 3 floats controlling length-width-height ratio. This adds meaningful context beyond the bare schema, though it doesn't specify exact float ranges or units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate 3D asset using Hyper3D by giving description of the desired asset, and import the asset into Blender.' It specifies the verb (generate), resource (3D asset), and destination (Blender). However, it doesn't explicitly distinguish this from its sibling 'generate_hyper3d_model_via_images', which uses images instead of text prompts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning the text prompt must be in English and that re-scaling after generation can be useful. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like 'generate_hunyuan3d_model' or 'generate_hyper3d_model_via_images', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool imports an asset and returns success status, but lacks details on permissions, error handling, rate limits, or what 'imported successfully' entails (e.g., file location, format). This is inadequate for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by parameter details and a key usage rule. Every sentence adds value without redundancy, and it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers basic purpose, parameters, and usage context. However, as a mutation tool, it lacks details on behavioral traits (e.g., side effects, error cases) and output specifics, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the purpose of each parameter ('name of the object in scene', 'task_uuid for MAIN_SITE mode', 'request_id for FAL_AI mode') and adds critical guidance to 'Only give one of {task_uuid, request_id} based on the Hyper3D Rodin Mode!' This significantly clarifies parameter usage beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import') and resource ('asset generated by Hyper3D Rodin'), specifying it occurs 'after the generation task is completed.' It distinguishes from siblings like 'import_generated_asset_hunyuan' by focusing on Hyper3D Rodin, but could be more explicit about the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use ('after the generation task is completed') and specifies parameter usage based on Hyper3D Rodin Mode (MAIN_SITE vs. FAL_AI). However, it does not 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes key traits: it's a polling API, returns statuses like 'DONE' or 'RUN', and includes the ZIP file path when done. However, it lacks details on error handling (e.g., failed states), rate limits, authentication needs, or whether it's read-only/destructive. This provides basic context but leaves gaps for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but has some redundancy. It repeats information about the 'ResultFile3Ds' field in two sentences. The structure is front-loaded with the core purpose, but the later sentences could be streamlined. Overall, it's understandable but not optimally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a polling tool for 3D generation), no annotations, no output schema, and 0% schema coverage, the description is somewhat complete. It covers the purpose, parameter, return values, and behavioral context like polling. However, it lacks details on error states, output structure beyond status, and integration with siblings like 'generate_hunyuan3d_model'. This makes it adequate but with clear gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explicitly documents the single parameter 'job_id' and explains its purpose: 'The job_id given in the generate model step.' This adds meaningful semantics beyond the bare schema, clarifying where the job_id comes from. Since there's only one parameter, this is sufficient for a high score, though it doesn't cover format or constraints in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 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', which appears to serve a similar function, preventing 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: 'This is a polling API, so only proceed if the status are finally determined.' It implies usage for checking completion status of a generation task, likely after invoking 'generate_hunyuan3d_model'. However, it doesn't explicitly state when not to use it or name alternatives like 'get_hunyuan3d_status', which could be a similar sibling tool.
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 states the tool downloads and imports, implying a write/mutation operation, but doesn't disclose permissions needed, whether it overwrites existing files, network/rate limits, or what 'import into Blender' entails (e.g., adds to current scene). The return message description 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a clear purpose statement followed by a bulleted parameter list with explanations. Every sentence earns its place, with no redundant or vague phrasing. It's appropriately sized for a 4-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers parameter semantics well but lacks critical behavioral context (e.g., side effects, error conditions, what 'import' means operationally). The vague return statement doesn't compensate for missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantic meaning for all 4 parameters: asset_id (ID to download), asset_type (type like hdris), resolution (e.g., 1k), and file_format (optional format per type). It adds value beyond the bare schema by explaining what each parameter represents and giving examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Download and import'), the resource ('a Polyhaven asset'), and the target environment ('into Blender'). It distinguishes this tool from siblings like 'search_polyhaven_assets' (which only searches) 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to obtain and use a Polyhaven asset in Blender, but provides no explicit guidance on when to choose this tool over alternatives like 'download_sketchfab_model' or 'import_generated_asset'. It mentions optional parameters but doesn't clarify when they're needed versus using defaults.
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 a 3D asset with built-in materials, imports it into Blender, and normalizes size. It mentions success/failure returns but doesn't cover behavioral traits like required permissions, rate limits, error handling, or what 'import into Blender' entails operationally. The description adds some context but leaves 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/5Is 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 key details (materials, scaling), then a structured parameter section. Every sentence adds value, but the parameter explanations could be more integrated (e.g., merging mode dependencies into the purpose). No wasted words, but minor structural improvements are possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (3 parameters, 0% schema coverage, no output schema, no annotations), the description is moderately complete. It covers purpose, parameters, and basic behavior but lacks details on output (only 'success or failure' message), error cases, integration with Blender, or dependencies on other tools (e.g., status checks). For a tool with multiple parameters and no structured support, it should do more to guide usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds significant meaning: it explains that input_image_paths requires absolute paths and is for MAIN_SITE mode, input_image_urls is for FAL_AI mode, both must be lists, and bbox_condition controls [Length, Width, Height] ratio as a list of 3 ints. This clarifies usage beyond the bare schema, though it doesn't detail format constraints (e.g., image types) or default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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), resource (3D asset), method (via images), and destination (Blender). However, it doesn't explicitly differentiate from its sibling 'generate_hyper3d_model_via_text', which uses text input instead of images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it specifies that only one of {input_image_paths, input_image_urls} should be given depending on Hyper3D Rodin's current mode (MAIN_SITE vs FAL_AI). It also mentions re-scaling after generation can be useful. However, it doesn't explicitly state when to use this tool versus alternatives like 'generate_hunyuan3d_model' or 'import_generated_asset', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Capture') and return type ('Returns the screenshot as an Image'), but lacks details on permissions needed, whether it's read-only or modifies state, error conditions, or performance characteristics (e.g., if it pauses rendering). It adequately describes the core behavior but misses nuanced operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a brief parameter explanation and return statement. Every sentence earns its place with no redundant or verbose language, making it highly efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter) and no output schema, the description is mostly complete: it states the action, parameter meaning, default, and return type. However, without annotations or output schema, it lacks details on error handling, image format, or viewport state requirements (e.g., must be in a 3D view), leaving minor gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It explains the single parameter 'max_size' as 'Maximum size in pixels for the largest dimension' and provides the default value (800), adding clear meaning beyond the schema's title and type. However, it doesn't specify constraints (e.g., minimum/maximum values) or how aspect ratio is handled, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the 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. 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a screenshot of the Blender viewport is needed, but provides no explicit guidance on when to use this tool versus alternatives (e.g., other screenshot methods or tools for different visual outputs). There are no exclusions or prerequisites mentioned, leaving usage context somewhat open-ended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it downloads and imports, scales the model, requires access rights, and returns import details. It doesn't cover potential errors, rate limits, or exact output format, but adds substantial value beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, parameter explanations, and return details. It's front-loaded with key information, though the examples for 'target_size' are slightly verbose but still useful. Every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides good context for a 2-parameter tool: it explains what the tool does, parameters, returns, and prerequisites. It could improve by detailing error cases or exact return structure, but it's largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does so by clearly explaining both parameters: 'uid' as the unique identifier and 'target_size' as required with detailed examples and units. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Download and import'), the resource ('a Sketchfab model by its UID'), and the key behavior ('scaled so its largest dimension equals target_size'). It distinguishes itself from siblings like 'search_sketchfab_models' by focusing on downloading/importing rather than searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific model UID and want to import it with size control, but it doesn't explicitly state when to use this tool versus alternatives like 'import_generated_asset' or prerequisites beyond access rights. It mentions 'The model must be downloadable and you must have proper access rights,' which provides some context but not explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well. It discloses that this is a polling API, advises to proceed only when status is finally determined, explains what constitutes completion vs. failure for each mode, and describes the return format (list of status or single status). It doesn't cover rate limits, authentication needs, or error handling details, but provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. It uses bullet-like formatting for parameters and returns, making it scannable. Some redundancy exists (e.g., repeating 'This is a polling API' for each mode), but overall it's efficient with zero wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (two operational modes, polling behavior) and lack of annotations/output schema, the description is quite complete. It covers purpose, parameters, return interpretation, and behavioral constraints. It could improve by explicitly mentioning error states or timeouts, but for a status-checking tool, it provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 does so excellently: it explains that 'subscription_key' is used for MAIN_SITE mode (given in generate step) and 'request_id' for FAL_AI mode (given in generate step), adding crucial meaning beyond the bare schema. This clarifies when to use each parameter based on the operational mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking if a Hyper3D Rodin generation task is completed. It specifies the exact resource (Hyper3D Rodin generation task) and verb (check status), distinguishing it from siblings like 'get_hyper3d_status' or 'poll_hunyuan_job_status' by focusing specifically on Rodin mode tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: after initiating a generation task and needing to poll for completion. It distinguishes between two modes (MAIN_SITE and FAL_AI) with different parameters. However, it doesn't explicitly state when not to use it or name specific alternatives among siblings, though the context implies it's for Rodin-specific tasks.
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 that the tool returns a thumbnail 'as an Image for visual confirmation,' which is useful behavioral context. However, it lacks details on potential errors (e.g., invalid UID), rate limits, or authentication needs, leaving gaps for a tool with no 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by usage guidance and parameter details in a structured format. Every sentence adds value without redundancy, making it efficiently sized and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete: it covers purpose, usage, and parameter semantics. However, it lacks output details (e.g., image format or size) and error handling, which could be useful for an agent, though not critical for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds significant meaning by explaining that 'uid' is 'The unique identifier of the Sketchfab model' and specifying it's 'obtained from search_sketchfab_models,' which clarifies the parameter's purpose and source beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('preview thumbnail of a Sketchfab model'), and it distinguishes from siblings like 'download_sketchfab_model' by focusing on previewing rather than downloading. The phrase 'visually confirm a model before downloading' reinforces this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Use this to visually confirm a model before downloading') and references a sibling tool ('search_sketchfab_models') as the source for the UID parameter, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/opslon/blender-mcp-optimized'
If you have feedback or need assistance with the MCP directory API, please join our Discord server