BlenderMCP

Server Quality Checklist

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

Latest release: v1.5.5
Disambiguation3/5
The tools have clear domains (Polyhaven, Sketchfab, Hyper3D, Hunyuan3D, scene operations), but there is notable overlap within domains: three separate generate tools for 3D assets (Hunyuan3D, Hyper3D via images, Hyper3D via text) serve similar purposes with different backends, and two separate import_generated_asset tools could confuse agents about which to use. However, descriptions help differentiate them by specifying the source.
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. There are minor deviations like 'execute_blender_code' (which uses 'execute' instead of 'run' or similar) and some longer names, but overall the naming is predictable and readable across the set.
Tool Count3/5
With 22 tools, the count is borderline high for a Blender integration server, leaning toward heavy. While the tools cover multiple domains (asset downloading, 3D generation, scene info, status checks), some could be consolidated (e.g., multiple generate and import tools) to reduce complexity without losing functionality.
Completeness4/5
The tool set provides comprehensive coverage for asset downloading (Polyhaven, Sketchfab), 3D generation (Hunyuan3D, Hyper3D), and scene management (info, screenshots, textures). Minor gaps exist, such as no direct tools for editing objects or managing materials beyond textures, but core workflows for importing and generating assets are well-supported with status checks and polling.
Average 3.7/5 across 22 of 22 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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?
Lacks annotations, so description must carry full burden. Mentions returning a message about availability, but provides no context about network requirements, authentication, or caching behavior. The cryptic instruction about 'key type' and 'sliently remembering it' adds confusion without explaining what the key type is or why it matters.
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?
First two sentences are efficient and front-loaded. The third sentence ('Don't emphasize the key type...') contains a typo ('sliently'), reads as meta-instruction to the AI rather than tool documentation, and breaks the informational flow without clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple status tool with no output schema, explaining the basic return value (message about availability). However, given the mysterious 'key type' reference and lack of return structure details, it leaves significant gaps about what information the tool actually provides.
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?
Zero parameters present; baseline score per rubric. Description does not need to compensate for parameter documentation.
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?
Clear verb ('Check') and resource ('Hyper3D Rodin integration') with specific scope (enabled status in Blender). Distinguishes from sibling status tools like get_hunyuan3d_status through explicit naming of the Hyper3D service.
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?
Fails to specify when to invoke this tool (e.g., 'before calling generate_hyper3d_model_via_text') or prerequisite conditions. No mention of alternatives or when not to use it, despite having clear sibling relationships with the generation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden but only mentions it returns a 'list' without specifying format (strings vs objects), pagination behavior, or error handling for invalid asset types. Fails to mention if this is a cached read or live API call.
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?
Appropriately brief with two logical sections. The explicit parameter listing is necessary given schema deficiencies, though the ':' formatting is slightly redundant with structured schema presentation. No wasted sentences, but could be more front-loaded with return value info.
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?
Adequate for a single-parameter tool, but lacks description of return values since no output schema exists. Given the low complexity (1 optional param), the description meets minimum viability but would benefit from sample return format or workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage (no description field in schema), the description compensates effectively by documenting the asset_type parameter and explicitly listing valid values: 'hdris, textures, models, all'. This is exactly the information the schema lacks.
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 'categories' with scope 'for a specific asset type on Polyhaven'. It implicitly distinguishes from sibling search_polyhaven_assets by focusing on category metadata rather than asset search, though explicit differentiation would strengthen it further.
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 provided on when to use this versus search_polyhaven_assets or get_polyhaven_status. No mention of prerequisites (e.g., checking status first) or typical workflow placement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Get' implying read-only, but fails to disclose whether this modifies the current selection state in Blender viewport, what 'detailed information' encompasses (transforms, mesh data, materials), or any error conditions if object doesn't exist.
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?
Appropriately compact with clear front-loaded purpose statement followed by parameter documentation. No redundant text, though parameter section is minimal. Structure follows logical flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema provided and zero schema coverage, the description should ideally characterize what 'detailed information' means (e.g., transforms, vertex counts, material slots). Single parameter is documented, but return value remains opaque.
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 has 0% description coverage (only title 'Object Name'), so description provides crucial semantic context: 'The name of the object to get information about'. This successfully 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' and resource 'detailed information about a specific object in the Blender scene'. The phrase 'specific object' effectively distinguishes it from sibling tool get_scene_info which operates at the scene level, though explicit sibling naming would strengthen this further.
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 provided on when to use this versus alternatives like get_scene_info (which returns all objects) versus when to use more specific object queries. No prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get' implying read-only access, but fails to specify what 'detailed information' includes (hierarchy, materials, render settings?), the output format, or potential side effects when no scene is loaded.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is efficient and front-loaded, but given the lack of annotations and output schema, the extreme brevity leaves critical behavioral and return-value gaps that a second sentence could have addressed.
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?
Adequate for identifying the tool's basic function, but incomplete regarding the data returned and how it differs from 'get_object_info'. With no output schema provided, the description fails to compensate by describing the expected return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters. Per scoring rules, zero parameters establishes a baseline of 4, as there are no parameter semantics to clarify beyond what the empty schema conveys.
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?
States a clear verb ('Get') and resource ('detailed information about the current Blender scene'). Implicitly distinguishes from sibling 'get_object_info' via scope (scene vs. object), though it does not explicitly clarify what scene-specific data is returned or name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus 'get_object_info' or other data-retrieval siblings, nor mentions prerequisites like having an active Blender scene.
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 commendably specifies the return type (Image), but omits other critical behavioral traits such as required viewport visibility, image format/encoding, side effects on the application state, or error conditions (e.g., failing if the viewport is minimized).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with three distinct sections (purpose, parameters, return value) and concisely delivers necessary information. The informal 'Parameters:' list is redundant with the schema but necessary given the schema's lack of descriptions.
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 tool with low complexity (one optional parameter) and no output schema, the description minimally suffices by indicating the return format. However, given zero annotations and no output schema, it should ideally specify behavioral constraints (e.g., requires GUI mode, viewport must be visible) to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage (the parameter lacks a description field), the description compensates effectively by explaining that max_size constrains the 'largest dimension' and noting its default value (800), adding semantic clarity beyond the schema's type integer.
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 specific action (capture) and resource (screenshot of the current Blender 3D viewport). It implicitly distinguishes from siblings like get_scene_info or execute_blender_code by specifying 'viewport,' though it doesn't explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., executing custom Python code via execute_blender_code to capture specific buffers) or prerequisites (e.g., requiring an active viewport).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that filtering is optional and that the return is a list with basic information, but omits rate limits, pagination behavior, or error handling (e.g., empty results).
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?
Well-structured with front-loaded purpose statement followed by parameter details. Given zero schema descriptions, the 'Parameters:' section adds necessary value rather than redundancy. Slightly verbose but 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?
Adequate for a simple 2-parameter search tool with no output schema—the description explains the return value (list with basic info). However, it misses the opportunity to link to get_polyhaven_categories for valid filter values, which is relevant given the sibling tool exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no property descriptions). The description compensates well by documenting valid enum values for asset_type (hdris, textures, models, all) and explaining the comma-separated format for categories. Loses one point for not referencing get_polyhaven_categories to discover valid category strings.
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?
States specific verb (Search) and resource (assets on Polyhaven), and distinguishes from sibling search_sketchfab_models by explicitly naming the platform. Could be clearer about scope (e.g., CC0 assets only) but adequately describes the core function.
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?
Lacks explicit guidance on when to use versus download_polyhaven_asset or when to call get_polyhaven_categories first to discover valid category values. Mealy describes functionality without workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It successfully documents default values and states it 'Returns a formatted list,' providing some output context. However, it lacks safety information (read-only status), rate limits, or pagination 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 well-structured with a clear purpose statement upfront, followed by parameter documentation and return value information. Every sentence adds value, and the formatting is clean despite being embedded in description text.
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% schema coverage and no output schema, the description adequately covers the 4 parameters and mentions the return type. However, it lacks detail on the return value structure (what fields constitute a 'formatted list') and valid category values, leaving gaps for a search tool.
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%, requiring the description to compensate. It excellently documents all 4 parameters, including critical format constraints like 'comma-separated' for categories and semantic context like 'Maximum number of results' for count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), resource ('models on Sketchfab'), and scope ('optional filtering'). While clear, it does not explicitly differentiate from sibling tools like download_sketchfab_model or get_sketchfab_model_preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., when to search vs. directly downloading) or any prerequisites. The phrase 'optional filtering' implies capability but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full disclosure burden. It fails to declare the read-only/safe nature of the operation. While it mentions a returned 'message' and a 'key type,' it offers no definition of what 'key type' refers to (API key? license type?) and uses imperative phrasing ('Don't emphasize...') that describes AI handling rather than tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The third sentence ('Don't emphasize the key type...') is structured as a command to the AI agent rather than a description of the tool's behavior. This is stylistically inappropriate for a tool definition, creates confusion about whether the tool or the caller 'remembers' state, and wastes descriptive space without clearly explaining what 'key type' means.
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 zero-parameter status tool without output schema, it adequately identifies what is checked (integration enabled) and broadly what is returned (availability message). However, the unexplained reference to 'key type' leaves a gap in understanding the complete response payload, and the lack of safety descriptors (read-only) is notable given no annotations exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters, triggering the baseline score of 4. The description correctly implies no arguments are required for this status check.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') with a clear resource ('Hunyuan3D integration') and scope ('in Blender'). It effectively distinguishes from siblings like generate_hunyuan3d_model (generation vs. status checking) and poll_hunyuan_job_status (integration status vs. job status).
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?
Provides implied usage context—checking whether the integration is enabled suggests using it before attempting generation operations. However, lacks explicit guidance such as 'Call this before generate_hunyuan3d_model' or comparison with the similar get_hyper3d_status sibling.
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 disclosure burden. The chunking advice hints at stability/timeout concerns, but the description fails to explicitly state that execution modifies Blender's state, can crash the application, or detail what APIs (e.g., bpy) are available to the executed code.
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 core purpose, followed by critical usage advice, then parameter documentation. It is appropriately sized for the tool's complexity, though the parameter section is formatted as inline text rather than utilizing structured schema descriptions.
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 this is a high-risk code execution tool with no output schema and no annotations, the description is minimally viable but incomplete. It should disclose error handling behavior, execution environment constraints, and the namespace/modules available to the executed code to reach completeness for this complexity level.
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 adequately by specifying the 'code' parameter contains 'Python code to execute,' adding critical language context missing from the generic string schema. It stops short of detailing syntax requirements, available modules, or execution scope.
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 executes arbitrary Python code in Blender, using a specific verb and resource. While it distinguishes well from asset-focused sibling tools like 'download_polyhaven_asset' or 'import_generated_asset', it could be elevated to a 5 by explicitly contrasting this low-level code execution with the higher-level scene manipulation alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific procedural guidance ('break it into smaller chunks'), implying the tool prefers incremental execution. However, it lacks explicit 'when to use' criteria comparing code execution against individual scene manipulation tools, and provides no 'when not to use' constraints or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses material properties, normalized sizing needs, and auto-import behavior. However, fails to mention asynchronous/job-based nature despite existence of poll_rodin_job_status and get_hyper3d_status siblings, which is critical behavioral context given the annotation absence.
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?
Clear three-part structure (purpose/behavior, parameters, returns). Front-loaded with primary action. No redundant sentences. Parameters section uses informal but readable formatting rather than strict schema documentation style.
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?
Adequate for basic invocation but omits critical workflow context: job polling mechanics implied by sibling tools, Hyper3D service availability checks, and Blender session requirements. Return value description is minimal but acceptable given lack of output 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?
With 0% schema coverage, description fully compensates by explaining both parameters: text_prompt constraints (English, short) and bbox_condition format (list of 3 floats, ratio meaning). Could elaborate on valid value ranges or coordinate system for bbox.
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?
States specific action (Generate 3D asset), identifies service (Hyper3D), and discloses key side effect (import into Blender). Differentiates implicitly from image-based sibling via 'giving description' phrasing, though explicit contrast with generate_hyper3d_model_via_images would strengthen this to 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?
Implies text-to-3D use case through parameter descriptions, but lacks explicit 'when to use' guidance or contrast with generate_hunyuan3d_model or image-based alternatives. No mention of workflow prerequisites (e.g., Blender running).
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 adds valuable context by specifying the return value indicates import success and establishing the temporal dependency on generation completion. However, it omits details about failure modes, idempotency, or side effects like scene modification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear visual separation between the purpose statement, parameter definitions, and return value description. Every sentence serves a distinct function without redundancy, though the parameter descriptions could be slightly more detailed regarding format constraints.
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 limited complexity (2 parameters, no output schema) and workflow integration with Hunyuan3D generation, the description provides sufficient baseline information for invocation. However, it leaves gaps regarding error handling, ZIP file content requirements, and behavior when the object name already exists in the scene.
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 effectively compensates by providing semantic meaning for both parameters: 'name' clarifies it refers to the object name in the scene, and 'zip_file_url' references its origin in the generation step. These descriptions add necessary context beyond the bare schema titles.
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), resource (asset generated by Hunyuan3D), and workflow timing (after generation task is completed). It implicitly distinguishes from the sibling 'import_generated_asset' by specifying 'Hunyuan3D', though it doesn't explicitly clarify when to use this variant versus the generic import tool.
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 context by stating 'after the generation task is completed' and referencing 'the generate model step' in the zip_file_url parameter. However, it lacks explicit guidance on when to choose this tool over the sibling 'import_generated_asset' or error handling prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It acknowledges the import side effect ('import into Blender') and return type ('message indicating success or failure'), but lacks critical behavioral context: it does not mention network requirements, disk storage of downloaded files, error conditions, or scene modification implications.
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 uses a clean, structured format with clear 'Parameters:' and 'Returns:' sections. Every line serves a purpose—either describing the operation or documenting parameters. No redundant or filler text.
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 4 parameters with 0% schema coverage and no annotations/output schema, the description adequately covers parameter meanings but remains incomplete regarding workflow context (necessity of prior search) and failure modes for an external API-dependent tool.
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 fully compensates by documenting all 4 parameters with concrete examples (e.g., 'hdris, textures, models' for asset_type; conditional file_format mappings). This adds substantial semantic value beyond the naked schema, though it could clarify parameter relationships (required vs optional) explicitly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Download and import') and identifies the exact resource ('Polyhaven asset') and destination ('Blender'). It clearly distinguishes from siblings like search_polyhaven_assets or download_sketchfab_model by specifying the Polyhaven source and dual download-import action.
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?
While the description identifies what the tool does, it provides no explicit guidance on when to use it versus alternatives, prerequisites (e.g., that asset_id must be obtained from search_polyhaven_assets first), or when not to use it (e.g., for Sketchfab models or local files).
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 successfully explains the state machine (DONE vs RUN vs failed), reveals the specific return structure (ResultFile3Ds containing a ZIP path), discloses the file format (OBJ), and characterizes the polling nature of the API.
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 front-loaded with the purpose but contains redundancy: it describes ResultFile3Ds twice in consecutive sentences with slightly different wording. The 'Parameters:' section uses unusual indentation. The information is valuable but could be more efficiently structured.
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 no output schema exists, the description appropriately explains return values (status strings and ResultFile3Ds field). It covers the essential polling workflow and completion states necessary for an agent to use this tool effectively within the Hunyuan3D job lifecycle.
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 for the job_id parameter. The description compensates adequately by explaining that job_id is 'The job_id given in the generate model step', providing semantic context about the parameter's source and relationship to the workflow.
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 'Check[s] if the Hunyuan3D generation task is completed' and identifies itself as a 'polling API'. It distinguishes from the generation step (sibling generate_hunyuan3d_model) by referencing 'the job_id given in the generate model step'. However, it does not clarify when to use this versus the sibling get_hunyuan3d_status.
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 implicit workflow guidance by explaining the status values ('DONE', 'RUN', failed states) and advising to proceed only when status is finally determined. However, it lacks explicit when/when-not guidance compared to alternatives like get_hunyuan3d_status, and the 'only proceed' phrasing is slightly ambiguous.
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 behavioral burden. It discloses return value structures (list of status vs single status), enumerates specific status strings ('Done', 'Failed', 'COMPLETED', 'IN_PROGRESS', 'IN_QUEUE'), explains success/failure conditions, and explicitly identifies this as a polling API. No contradictions with annotations (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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is logically structured by mode (MAIN_SITE vs FAL_AI) but suffers from repetition—the 'This is a polling API...' warning appears twice with nearly identical wording. The content earns its place but could be consolidated into a single unified description without loss of clarity, reducing length by ~30%.
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 no output schema exists and parameters lack schema descriptions, the description adequately covers return value semantics for both API modes, status code interpretations, and polling termination conditions. It provides sufficient context for an agent to understand the complete lifecycle of the polling operation.
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 by explaining both subscription_key and request_id, including their provenance ('given in the generate model step') and conditional usage (which parameter for which mode). This provides essential semantic mapping missing from the JSON 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 'Check[s] if the Hyper3D Rodin generation task is completed' with specific verb and resource. It distinguishes from generic status tools by specifying 'Rodin' and differentiating between MAIN_SITE and FAL_AI modes. However, it does not explicitly contrast with sibling tool get_hyper3d_status to clarify when to use which Hyper3D status endpoint.
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?
Provides explicit preconditions: parameters come from 'the generate model step' and mandates 'only proceed if the status are finally determined.' It clearly documents the polling pattern and terminal states ('Done'/'Canceled' or 'COMPLETED'). Lacks explicit 'when not to use' alternatives (e.g., vs initial generation), but covers the critical polling workflow thoroughly.
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 'Returns a message indicating success or failure' (output behavior) and mentions the downloaded state prerequisite. However, it lacks disclosure of side effects (e.g., whether this overwrites existing materials, is reversible, or requires object selection).
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 three distinct sections: the core action, parameter documentation, and return value. Every sentence earns its place by conveying essential information without redundancy, appropriate for a two-parameter tool.
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 absence of schema descriptions and output schema, the description adequately covers these gaps by documenting parameters and mentioning the return value. For a focused 2-parameter mutation tool, this is sufficiently complete, though explicit error conditions or sibling tool references would strengthen it further.
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% (properties lack descriptions), requiring the description to compensate. It successfully adds semantic meaning to both parameters: clarifying object_name references the target object and texture_id requires the download prerequisite. It provides adequate compensation but does not specify expected formats or validation rules.
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 specific action (Apply) and resource (Polyhaven texture) with the target (object). It implicitly scopes the tool to downloaded Polyhaven assets by mentioning 'previously downloaded,' but lacks explicit contrast with sibling download_polyhaven_asset to fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance by stating the texture 'must be downloaded first,' which establishes the prerequisite and implies the correct sequence with download_polyhaven_asset. However, it does not explicitly name the sibling tool or describe error states when the prerequisite is violated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behaviors: async job flow (job_id, 'DONE' status), side effects ('import the asset into Blender'), and output characteristics ('built-in materials'). It does not cover rate limits or auth requirements.
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?
Well-organized with clear sections (purpose, parameters, returns). Front-loaded with the core action. The returns section is slightly verbose but necessary given the lack of output schema.
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 zero annotations, no output schema, and simple input types, the description adequately covers the async return pattern, import destination, and material properties. It could mention the existence of polling tools (poll_hunyuan_job_status) for status checking.
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 documenting both parameters in detail: text_prompt accepts 'English/Chinese' descriptions and input_image_url accepts 'local or remote url', including the 'Accepts None' constraint.
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 uses specific verbs ('Generate', 'import') and identifies the specific technology (Hunyuan3D) and target (Blender), distinguishing it from Hyper3D siblings. However, it lacks explicit comparison or selection criteria between Hunyuan3D and Hyper3D alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly explains input combinations ('either text description, image reference, or both') but provides no explicit guidance on when to use this tool versus the Hyper3D generators or other asset sources like Polyhaven/Sketchfab.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It partially satisfies this by stating the return value ('a message indicating whether Sketchfab features are available'), but omits details about what 'enabled' entails (API keys, network, addon state), error conditions, or side effects. For a zero-annotation tool, more behavioral context could be provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero waste. The first sentence establishes purpose, the second discloses return behavior. Every sentence earns its place and the description is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, simple boolean check), no annotations, and no output schema, the description is reasonably complete. It explains what is checked and what is returned. It could be improved by mentioning the specific implication (e.g., whether download_sketchfab_model will succeed), but covers the essentials adequately.
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 zero parameters (empty object), which establishes a baseline score of 4 per the calibration rules. The description appropriately does not invent parameters, though it could explicitly confirm no configuration is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('Sketchfab integration') and explicitly limits scope to 'in Blender'. It distinguishes clearly from siblings like get_hunyuan3d_status, get_hyper3d_status, and get_polyhaven_status by specifying 'Sketchfab', and from action-oriented siblings like download_sketchfab_model by stating this is a status check.
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 states what the tool does but does not explicitly state when to use it versus alternatives (e.g., 'Use this before downloading Sketchfab models'). The usage is implied by the 'status' nature of the tool, but lacks explicit guidance on prerequisites or relationship to sibling tools like download_sketchfab_model.
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 appropriately notes the tool returns a message about availability, indicating read-only behavior. However, it omits potential error conditions (e.g., if Blender is not running) or the specific format/content of the returned message.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first defines the action and target, second explains the return value. No redundancy or unnecessary elaboration for this simple status-check tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter status tool. The description mentions the return message弥补了 the lack of output schema, and specifies the Blender integration context. Could improve by indicating whether the check requires active Blender connection or handles offline states.
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?
Zero parameters exist, establishing a baseline of 4. The description does not need to elaborate on input parameters, and instead appropriately focuses on describing the operation and return value semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly defines the specific action ('Check') and resource ('PolyHaven integration status in Blender'), distinguishing it from siblings like get_sketchfab_status and download_polyhaven_asset by specifying the PolyHaven domain and read-only status check nature.
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?
Provides clear context for when to use the tool by stating it 'Returns a message indicating whether PolyHaven features are available,' which implicitly signals to check this before attempting PolyHaven operations. Lacks explicit mention of prerequisite relationships with download_polyhaven_asset or search_polyhaven_assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions return value ('Return if the asset has been imported successfully'), but omits side effects (where imported?), error behavior, or what 'MAIN_SITE' vs 'FAL_AI' modes entail. Adequate but not rich behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with dedicated Parameters section and clear constraint statement. Slightly awkward phrasing in 'Return if the asset has been imported successfully' but generally efficient with no wasted sentences.
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?
Adequately covers the 3-parameter input signature with complex conditional logic (mode-dependent IDs). References return status. Missing output schema is partially mitigated by success mention, though error formats and destination context (scene specifics) remain undocumented.
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?
Compensates perfectly for 0% schema coverage. Defines all three parameters: 'name' (object name in scene), 'task_uuid' (MAIN_SITE mode), 'request_id' (FAL_AI mode). Critical mutual exclusivity constraint documented: 'Only give one of {task_uuid, request_id}'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb (Import) + specific resource (asset generated by Hyper3D Rodin) + scope (after generation task completed). Explicitly naming 'Hyper3D Rodin' distinguishes from sibling tool 'import_generated_asset_hunyuan' and from generation tools like 'generate_hyper3d_model_via_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit parameter usage constraint: 'Only give one of {task_uuid, request_id} based on the Hyper3D Rodin Mode!' and implies prerequisite timing ('after the generation task is completed'). Lacks explicit cross-reference to alternative import tools (e.g., when to use Hunyuan variant instead).
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, description carries full burden. It discloses critical behavioral trait: automatic scaling so largest dimension equals target_size. It also describes return format ('message with import details') and access constraints, though it omits error handling or side effects like scene overwrite 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?
Well-structured with front-loaded purpose statement, followed by dedicated Parameters section with formatted examples, and Returns section. Every sentence adds value; no repetition of schema structure or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero schema descriptions, no annotations, and no output schema, description achieves completeness: fully documents both parameters, explains return value format, describes scaling behavior, and notes access prerequisites. No gaps remain unaddressed.
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 has 0% description coverage (titles only). Description fully compensates with extensive semantic details: uid defined as unique identifier, target_size explained with units (Blender units/meters) and five concrete domain examples (Chair: 1.0, Car: 4.5, etc.) that clarify expected value ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific actions (download and import) with specific resource (Sketchfab model by UID), and distinguishes from siblings like search_sketchfab_models and get_sketchfab_model_preview by focusing on the actual import workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisite constraints ('model must be downloadable', 'proper access rights'), but lacks explicit guidance on when to use this tool versus search_sketchfab_models or get_sketchfab_model_preview, or workflow sequencing.
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 discloses critical behavioral traits: the asset has built-in materials, the model has normalized size requiring potential re-scaling, and it returns a success/failure message. It also notes the import-to-Blender side effect. Missing disclosure of whether this is async/blocking (implied by existence of poll_rodin_job_status sibling but not stated) and what happens if both image inputs are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and appropriately structured with dedicated parameter explanations. Given the burden of documenting three undocumented schema parameters, the length is justified. Minor structural informality (separate 'Parameters:' section) does not impede 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?
For a 3-parameter tool with no annotations and 0% schema coverage, the description achieves strong completeness by covering input requirements, mutual exclusivity, behavioral side effects, and return values. Minor gaps remain regarding the async nature of the operation and constraints on number of input images supported.
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?
Given 0% schema description coverage, the description fully compensates by documenting all three parameters: it specifies absolute paths requirement, mandates list wrapping even for single items, explains bbox_condition controls dimensional ratios [L,W,H], and clarifies conditional requirements based on operation mode. This provides essential semantic context absent from the structured 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 opens with a specific action (Generate), target resource (3D asset using Hyper3D), input mechanism (via images), and side effect (import into Blender), clearly distinguishing it from sibling tool generate_hyper3d_model_via_text which uses text inputs instead.
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 explicitly documents the mutual exclusivity constraint between input_image_paths and input_image_urls, and indicates these depend on Hyper3D Rodin's current mode (MAIN_SITE vs FAL_AI). However, it lacks guidance on when to choose image-based generation over the sibling text-based tool or when to use this versus downloading existing assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return type ('Image for visual confirmation'), but lacks operational details like rate limits, validity of UIDs, image format/size, or network dependency on Sketchfab's API.
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?
Four compact sentences with zero redundancy: purpose statement, usage guidance, parameter documentation, and return value. Front-loaded with the core action. Structured logically despite not using strict markdown sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter retrieval tool without output schema. Description explains the return value (Image) and establishes sibling relationships. Minor gap: no error handling guidance (e.g., invalid UID behavior).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (uid property lacks description), but description fully compensates by explaining the parameter is 'obtained from search_sketchfab_models,' providing crucial semantic context for tool chaining. Minor deduction for not specifying UID format 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?
Description provides specific verb ('Get a preview thumbnail'), resource ('Sketchfab model'), and scope ('by its UID'). Clearly distinguishes from sibling 'download_sketchfab_model' (preview vs. download) and 'search_sketchfab_models' (specific retrieval vs. search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this to visually confirm a model before downloading,' establishing clear workflow context. Also references sibling 'search_sketchfab_models' as the UID source, creating explicit tool chaining guidance.
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/omniconnexsynapse/blender-mcp/badges/card.svg)](https://glama.ai/mcp/servers/omniconnexsynapse/blender-mcp)

Score Badge

Copy to your README.md:

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

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