BlenderMCP

Server Quality Checklist

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

Latest release: v1.8.0
Disambiguation5/5
Each tool targets a distinct resource and action. The integration-specific tools (PolyHaven, Sketchfab, Hyper3D, Hunyuan) are clearly separated by service, and the only potentially similar tools (generate_hunyuan3d_model vs generate_hyper3d_model_via_text/images) are distinguished by their backend and explicit naming.
Naming Consistency5/5
All tools follow a consistent verb_noun snake_case pattern (e.g., get_scene_info, download_polyhaven_asset, poll_rodin_job_status). There are no mixed conventions or ambiguous verb styles, making the tool surface highly predictable.
Tool Count4/5
At 22 tools, the set is slightly larger than the typical 3-15 range, but the server covers multiple distinct integrations (Blender core, PolyHaven, Sketchfab, Hyper3D, Hunyuan). Each tool contributes to a specific function, so the count is justified despite feeling heavy.
Completeness4/5
Core Blender operations (scene info, object info, screenshot, code execution) are well covered. Asset libraries and generation services have search/download/generate/poll/import workflows, but there are minor gaps such as lack of HDRI world application, no listing of downloaded assets, and no ability to edit objects beyond code execution. These are workaroundable via execute_blender_code.
Average 3.8/5 across 22 of 22 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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.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?
With no annotations, the description carries the full burden of behavioral disclosure, but it does not state whether this is a read-only operation, what 'detailed information' includes, or what happens if the object doesn't exist. The telemetry note about user_prompt is minor context but not sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short, leading with the purpose statement followed by concise parameter explanations. The inline parameter list is necessary given the schema lacks descriptions, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must clarify what 'detailed information' includes (e.g., transform, materials, parenting). It does not, leaving the agent uncertain about the return value's completeness for its intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description supplements the schema (which has 0% coverage) by explaining object_name as the target object's name and user_prompt as telemetry context. This adds essential meaning, though object_name could further specify format or case-sensitivity, and user_prompt's intended usage is clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific Blender object, using the verb 'Get' and specifying the resource. This distinguishes it from siblings like get_scene_info, which focuses on the whole scene, and other object/scene-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives (e.g., get_scene_info, get_viewport_screenshot) or any prerequisites, such as the object needing to exist. It simply states the action without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns a message indicating feature availability, which offers some transparency about output. However, with no annotations provided, it doesn't mention whether the operation is read-only, requires Blender to be running, or has any side effects. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose and a brief note on the return value. Every word earns its place; there is no unnecessary detail or repetition. It is appropriately sized for a simple status-check tool.
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?
The description sufficiently explains the tool's core function and return type, which is adequate for a simple status check. However, it is incomplete because it does not address the optional parameter, and it lacks usage guidance relative to sibling status tools. Given no annotations or output schema, more clarity on the parameter and when to use the tool would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (user_prompt) with no description in the schema, and the tool description does not mention it at all. With 0% schema coverage and no compensation in the description, the agent has no information about what 'user_prompt' is for or how to use it, making parameter semantics essentially absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check if PolyHaven integration is enabled in Blender.' It uses a specific verb ('Check') and resource ('PolyHaven integration'), and it distinguishes itself from sibling status tools like get_sketchfab_status and get_hunyuan3d_status by 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, recommended order (e.g., before searching assets), or exclusions. With many sibling tools, the lack of usage context leaves the agent without clear decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for disclosing behavior, but it only states that it gets information. It does not mention whether the operation is read-only, what specific information is returned, or whether there are any side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose. The parameter documentation is somewhat redundant with the schema, but it adds the telemetry context, so it earns its place. No fluff is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple info-gathering tool, it lacks a description of the return value, the kind of scene information provided, and any behavioral details. With no output schema and no annotations, the description alone is insufficient for an agent to know what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining that the user_prompt parameter is 'the original user prompt that led to this tool call (required for telemetry).' This clarifies that the parameter is for tracking purposes, not scene filtering, which the bare schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed information about the current Blender scene.' The verb 'get' and resource 'current Blender scene' are specific, and it is distinct from sibling tools like get_object_info or get_viewport_screenshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_object_info or execute_blender_code. The description implies a use case for retrieving scene information but does not state expected contexts 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, the description carries the full burden. It discloses that the tool returns a message indicating availability, which is useful, but it does not explicitly state whether the operation is safe/read-only or mention any side effects. Given the word 'Check' implies a read-only action, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, front-loaded sentences with no wasted words. The description states the action and the return behavior succinctly, appropriate for a simple status tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status check with no output schema or annotations, the description covers the core purpose and return type, but leaves gaps: the user_prompt parameter is unexplained, and the exact nature of the 'message' is vague. Enough for basic use, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter, user_prompt, with 0% schema description coverage, and the description does not mention it at all. This is a significant gap: the tool's purpose is a status check, and the parameter seems unrelated. The description provides no meaning for the parameter.
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 clearly identifies the resource ('Hunyuan3D integration') and context ('in Blender'). It distinguishes the tool from sibling status checks like get_hyper3d_status by explicitly naming Hunyuan3D.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a pre-flight check for Hunyuan3D features, but does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or exclusions. The intent is clear but not directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the action (checking integration) and the return type (a message indicating availability), but lacks details on preconditions, side effects, or error behavior. It is adequate for a simple read-only status check, but not richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and outcome. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description omits the user_prompt parameter entirely, which is confusing for a status checker. It also does not explain what the return message looks like or any prerequisites. Given the lack of output schema and annotations, the description is incomplete for a fully self-sufficient definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'user_prompt' with no description, and schema coverage is 0%. The description ignores this parameter entirely, giving no hint of its purpose or format. Since the parameter is optional and mysterious, the description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check if Hyper3D Rodin integration is enabled in Blender.' It uses a specific verb and resource, distinguishing it from sibling status tools like get_sketchfab_status or 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool to verify whether Hyper3D Rodin integration is enabled. It doesn't explicitly mention alternatives or exclusions, but the purpose statement inherently guides when to use it, and no other tool covers Hyper3D status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'download' and 'import' implying network usage and Blender scene modification, but it does not disclose specific behaviors such as whether the import is additive, what happens on failure, or any side effects. The only additional detail is that it returns a success/failure message, which is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear one-line purpose followed by a structured parameter list. It avoids unnecessary words and the structure makes the information easy to parse. Slight redundancy exists with the schema property names, but the added descriptions justify the length.
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?
The description covers the tool's purpose, parameters, and return value, which is adequate for a moderately simple download tool. However, it lacks context about prerequisites (e.g., Blender must be open, network availability), how this relates to search_polyhaven_assets, and specific error behavior. It is not incomplete enough to be confusing, but there are clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions are absent (0% coverage), but the tool description provides a one-line explanation for each parameter, including examples for asset_type (hdris, textures, models), resolution (1k, 2k, 4k), and file_format (hdr, exr, jpg, png, gltf, fbx). This adds meaningful semantics beyond the bare schema titles, helping an agent understand parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads and imports a Polyhaven asset into Blender, with a specific verb ('Download and import') and resource ('Polyhaven asset'). It distinguishes itself from sibling tools like download_sketchfab_model by naming Polyhaven.
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?
Usage is implied by the tool name and description: it should be used when a Polyhaven asset is needed. However, the description does not explicitly state when to use this tool versus alternatives like search_polyhaven_assets or download_sketchfab_model, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not mention that arbitrary code execution can be destructive, lacks undo, or that errors may occur. The step-by-step warning is minimal and does not convey the safety boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. It includes a brief execution tip and parameter list without redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (arbitrary code execution) and the lack of annotations or output schema, the description is insufficient. It does not address side effects, error handling, or the execution environment, making it incomplete for a safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates by clearly defining both parameters: code as Python code to execute and user_prompt as telemetry. It adds meaning beyond the schema, though it could be more explicit about code formatting or Blender's bpy availability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes arbitrary Python code in Blender, using a specific verb and resource. This distinguishes it from sibling tools like get_object_info or import_generated_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for general Blender scripting tasks but does not explicitly state when to use this tool versus dedicated alternatives. It provides a step-by-step execution tip, which is a how-to rather than a when-to-use guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It states the tool returns a message about availability, which is the core behavior, but does not disclose side effects, errors, or any additional behavioral nuances. This is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and adds no redundant information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status check tool, the description provides the essential return value and purpose. However, the undocumented parameter and lack of detail about the message format (no output schema) mean the description does not fully equip the agent to call the tool correctly, especially regarding what to pass for user_prompt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (user_prompt) with a default but no description, and the schema description coverage is 0%. The tool description does not mention the parameter at all, leaving its purpose and usage completely undefined. This is a severe gap in parameter 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?
The description uses a specific verb ('check') and clear resource ('Sketchfab integration in Blender'), and clarifies the return value. The 'status' tool is distinct from sibling tools like search_sketchfab_models or download_sketchfab_model, so differentiation is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use for verifying whether Sketchfab features are available before using other Sketchfab tools. However, it does not explicitly state when not to use this tool or name alternatives, so it lacks the explicit exclusions for a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses scaling behavior, return message content, and access rights, which is useful. However, it does not mention whether the import is additive to the scene, any failure modes, or potential side effects on existing objects, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose, followed by scaling behavior, parameter details, return info, and access rights. The parameter examples are helpful but slightly verbose; each sentence earns its place, though it could be tightened.
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, the description covers return values (import details) and prerequisites. It also explains the scaling behavior. However, the missing user_prompt parameter and lack of error/edge-case information prevent full completeness for a tool with 3 parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It provides detailed semantics for uid and target_size, including units and examples for target_size. However, it completely omits the user_prompt parameter (present in schema), leaving its purpose and usage undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads and imports a Sketchfab model by UID, distinguishing it from search, preview, and other download tools. The verb 'download and import' combined with the resource 'Sketchfab model' provides specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you have a Sketchfab UID) but does not explicitly state when to use this tool versus alternatives like search_sketchfab_models or get_sketchfab_model_preview. It includes prerequisites (access rights) but no direct exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some useful behavioral context: built-in materials, normalized size, re-scaling advice, and a success/failure message. It does not mention potential asynchronous behavior, scene modifications, prerequisites, or error handling beyond the return 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?
The description is concise and well-structured: a clear opening sentence, helpful asset traits, a Parameters section, and a Returns line. Every sentence adds value, and the front-loaded purpose makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core workflow is covered, but gaps remain: user_prompt is missing from the explanation, there is no mention of status polling or asset retrieval, and with no output schema or annotations, the tool's operational behavior is underspecified for a generation/import side-effecting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no property descriptions, and the description compensates for text_prompt (short English description) and bbox_condition (float[3] controlling L/W/H ratio). However, user_prompt is completely undocumented, so one parameter remains unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: generate a 3D asset using Hyper3D from a text description and import it into Blender. It distinguishes itself from sibling tools like generate_hyper3d_model_via_images through 'via text' and 'by giving description', making the resource and method explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: use when you want a text-described 3D asset in Blender. However, there is no explicit when-to-use guidance, exclusions, or comparison with alternatives such as image-based generation or other model generators.
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?
Despite no annotations, the description discloses the asynchronous job_id return, the import into Blender, built-in materials, and error behavior. It also indicates the status will change to DONE upon completion. This provides solid transparency, though it doesn't discuss potential side effects like overwriting existing assets.
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 an overview, parameter list, and returns section. It is free of fluff and front-loads the core purpose. The return explanation is somewhat verbose but informative, striking a balance between conciseness and necessary detail.
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?
The description covers the tool's purpose, parameters, and return behavior, including asynchronous job tracking and import completion. However, the missing user_prompt parameter and lack of input constraints (e.g., image format) leave gaps. Given there is no output schema, the description carries the full burden and is acceptable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains text_prompt and input_image_url with meaningful detail (e.g., 'short description' and 'local or remote URL'), but it omits user_prompt from the schema entirely. Since schema coverage is 0%, the description is the only source of parameter guidance, making the missing parameter a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Generate') and resource ('3D asset using Hunyuan3D'), and adds the import step into Blender. It distinguishes from sibling tools like generate_hyper3d_model_via_text by explicitly naming Hunyuan3D.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for generating a Hunyuan3D asset from text or image input, but does not explicitly mention alternatives or exclusions, such as using generate_hyper3d_model_via_text for Hyper3D or poll_hunyuan_job_status for status checks. Usage is implied, not contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the user_prompt is for telemetry, which adds context, but it does not state whether this is a read-only operation, any potential side effects, or what the response will contain. It is a simple list operation, so lack of detail is acceptable but not ideal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence and a structured parameter list. It avoids redundancy and is appropriately sized, though it could be slightly more organized with the parameter details visually separated more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description is mostly complete but lacks details about the return format, whether categories are hierarchical, or any limitations. It does not mention how to interpret the results, but given the simplicity, this is a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains both parameters: asset_type with its possible values (hdris, textures, models, all) and user_prompt with its telemetry purpose. Since the schema has no property descriptions (0% coverage), this fully compensates and adds significant meaning beyond the field names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a list of categories for a specific asset type on Polyhaven, specifying the verb (get), resource (categories), and scope (asset type). This distinguishes it from sibling tools like search_polyhaven_assets or download_polyhaven_asset, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (when you need categories for an asset type) but does not explicitly state when to use it versus alternatives or any prerequisites. There is no mention of related tools like get_polyhaven_status, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return type (thumbnail as Image) and implies a read-only preview, but it does not address error handling, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: an action statement, a usage context, a parameter list, and a return statement. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple preview tool, it covers the core purpose and return value, but it omits the user_prompt parameter and any error/failure behavior. With no output schema or annotations, these gaps make it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter descriptions, so the description must compensate. It explains the 'uid' parameter and its source (search_sketchfab_models), which is useful. However, the optional 'user_prompt' parameter is left completely unexplained.
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 states a clear verb+resource: 'Get a preview thumbnail of a Sketchfab model by its UID.' It distinguishes from siblings by noting the thumbnail confirms a model before downloading, and the UID comes from search_sketchfab_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit when-to-use: 'Use this to visually confirm a model before downloading.' It implies a distinction from the download tool but does not explicitly name alternatives or give when-not-to-use conditions.
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 disclose key behaviors: statuses ('DONE', 'RUN'), the meaning of DONE (returns ResultFile3Ds), and the polling nature. It lacks details on failure states or rate limits, but for a simple polling tool, the disclosed behavior is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose but contains redundancy: the return value is described twice ('returns ResultFile3Ds, which is the generated ZIP model path' and 'the response includes a field named ResultFile3Ds that contains the generated ZIP file path'). This repetition makes it less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers purpose, parameter semantics, statuses, and return format. It does not mention next steps (e.g., importing the asset) or error handling, but for a straightforward polling tool, it is reasonably 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?
The schema provides no description for job_id (0% coverage). The description compensates by explaining 'job_id: The job_id given in the generate model step,' which tells the agent where to obtain the value. It does not specify type or format, but the provenance is valuable and adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check if the Hunyuan3D generation task is completed.' It identifies the resource (Hunyuan3D task) and the action (poll for status). However, it does not differentiate this from sibling tools like get_hunyuan3d_status, so it loses a point for lack of explicit sibling 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides usage context by mentioning this is a polling API and instructs to 'only proceed if the status are finally determined (DONE or some failed state).' It also ties the job_id to the generate step. However, it does not mention alternatives or exclusions for when to use this versus sibling status-check 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 only states that it 'Returns a formatted list' and gives parameter defaults, but does not mention network/API requirements, authentication, error handling, or explicitly confirm that it is a read-only operation. This is insufficient for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a bulleted parameter list, and a return statement. It contains no extraneous words and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, most parameters, and the return type, but omits the user_prompt parameter and does not discuss behavior for no results or error cases. With no output schema or annotations, more detail on edge cases and potential failure modes would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, yet the description compensates by explaining query, categories, count, and downloadable with meanings and defaults. However, the user_prompt parameter is missing from the description and is not explained in the schema, which prevents a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for models on Sketchfab' with a specific verb and resource, distinguishing it from sibling tools like download_sketchfab_model and search_polyhaven_assets. It also mentions 'optional filtering' and the return of a formatted list, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is the tool for searching Sketchfab models, with optional filters such as categories and downloadable. However, it does not explicitly provide exclusions or mention alternatives, like when to use search_polyhaven_assets or get_sketchfab_model_preview instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It mentions the return message and the download prerequisite, but it doesn't disclose side effects like whether existing object materials are overwritten or what happens if the object doesn't exist. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a single purpose sentence, a minimal parameter list, and a return-value statement. No unnecessary words or redundancy.
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?
The tool is simple, but the description doesn't fully complete the picture: user_prompt is undocumented, and there is no mention of error behavior or effect on existing object textures. The return value is mentioned, so it's not wholly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains object_name and texture_id clearly, including the constraint that texture_id must be downloaded first. However, the schema's user_prompt parameter is completely omitted from the description, leaving its purpose unexplained.
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 'Apply' with a clear resource ('previously downloaded Polyhaven texture') and target ('object'). It effectively distinguishes the tool from siblings like download_polyhaven_asset and search_polyhaven_assets by focusing on the application step.
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 clearly states the prerequisite that the texture must be downloaded first, providing context for when the tool is appropriate. It doesn't explicitly mention alternatives or when not to use it, but no close alternative exists among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return type (Image) and explains the max_size and user_prompt parameters, but it does not explicitly state that the operation is non-destructive, require a running Blender instance, or describe any failure modes. This is moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with the main purpose, followed by a clear parameter list and return type. Every sentence adds value, and no unnecessary details are included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple screenshot tool, the description covers the essential aspects: what it does, parameters, and return type. It lacks explicit notes on prerequisites (e.g., Blender must be open) or potential errors, but given the simplicity, it is fairly 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?
The description provides meaningful explanations for both parameters: max_size is described as 'Maximum size in pixels' and user_prompt as 'original user prompt... for telemetry'. This goes beyond the schema's bare types and defaults. However, the stated default for max_size (800) conflicts with the schema's default (1000), which detracts slightly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Capture') and resource ('screenshot of the current Blender 3D viewport'). This distinguishes it from sibling tools like get_scene_info or execute_blender_code, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies when to use it (when a viewport screenshot is needed), but there is no explicit guidance on when to use it vs alternatives like get_scene_info or execute_blender_code. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses a prerequisite (after generation task completed), the need to provide exactly one of task_uuid/request_id, and that it returns whether import succeeded. However, it does not describe side effects like scene modification, error handling, or idempotency. There is no contradiction with annotations since none 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 efficiently structured, front-loading the purpose and then providing a clear parameter breakdown. The warning about mutually exclusive IDs is useful and concise. Though slightly verbose with the line-by-line parameter listing, it remains well-organized and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description covers the core purpose, prerequisites, and return status. However, it lacks explicit differentiation from the Hunyuan import tool, and it does not address error cases or the behavior if the asset already exists. Given the rich sibling context, a cross-reference or additional behavioral notes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description compensates by explaining each parameter's meaning and the conditional usage of task_uuid vs request_id based on mode. It also warns not to provide both, adding significant meaning beyond the schema's bare titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Import the asset generated by Hyper3D Rodin after the generation task is completed.' This specifies the action (import), the resource (Hyper3D Rodin-generated asset), and the timing (after generation). It also distinguishes from the sibling tool import_generated_asset_hunyuan by referring explicitly to Hyper3D Rodin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool ('after the generation task is completed') and gives explicit guidance on selecting between task_uuid and request_id based on the Hyper3D Rodin mode ('Only give one of {task_uuid, request_id} based on the Hyper3D Rodin Mode!'). However, it does not explicitly mention alternatives or conditions when not to use this tool, such as for Hunyuan-generated assets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full behavioral disclosure burden. It only states the prerequisite and that it returns success, but omits details about side effects (e.g., whether it adds to the scene or overwrites existing objects), error conditions if the task isn't complete, and the exact return format. This is minimal transparency for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a parameter list, with the purpose stated first. Every sentence is necessary and there is no redundant fluff. The structure is efficient and 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?
For a simple two-parameter tool with no output schema, the description covers the essential workflow (after generation), the parameters, and the return value ('if the asset has been imported successfully'). It lacks error-handling details but is adequate for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful explanations for both parameters: 'name' is the object name in the scene, and 'zip_file_url' is specifically the one from the generate model step. This is valuable because the input schema provides no descriptions (0% coverage), making the description the sole source of parameter 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?
The description clearly states a specific action ('Import'), a specific resource ('asset generated by Hunyuan3D'), and a timing condition ('after the generation task is completed'). This distinguishes it from the generic sibling 'import_generated_asset' by explicitly naming Hunyuan3D as the source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: it must be used after the generation task is completed, and it references the 'zip_file_url given in the generate model step', linking it to the generate_hunyuan3d_model workflow. However, it does not explicitly state when not to use it (e.g., for non-Hunyuan assets) or mention alternative tools by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the asset has built-in materials, a normalized size (suggesting re-scaling), and that the tool imports the asset into Blender. It also notes the return message indicating success/failure. This is substantial behavioral information, though it omits potential async behavior or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a parameter list and concise sentences. It front-loads the core purpose and follows with essential details. A few extra details (e.g., 'built-in materials') are useful, and nothing feels redundant.
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 and no annotations or output schema, the description covers most critical aspects (modes, bbox, materials, size, return message). However, it omits the user_prompt parameter, doesn't clarify whether the mode refers to environment settings, and lacks details on asynchronous behavior or potential side effects in Blender beyond import.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining that input_image_paths/input_image_urls must be lists, which one to use depending on mode, and that bbox_condition must be a list of three ints controlling L/W/H. However, it fails to mention the user_prompt parameter present in the schema, which is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 3D asset from images using Hyper3D and imports it into Blender. This specific verb+resource+outcome distinguishes it from siblings like generate_hyper3d_model_via_text (which uses text) and import_generated_asset (which likely only imports, not generates).
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 explains the mode-dependent requirement for input_image_paths vs input_image_urls, and instructs to use only one at a time. It provides clear context but does not explicitly mention alternatives like 'use generate_hyper3d_model_via_text for text-based generation'. Still, the guidance is solid enough for correct parameter selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return behavior (list of matching assets with basic information) and notes that user_prompt is for telemetry. With no annotations provided, the description carries the burden and does a reasonable job, though it doesn't mention any side effects or limitations beyond that.
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 short and structured: one-line purpose, parameter list, and return statement. It avoids unnecessary detail and is 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?
The description covers the core functionality, parameters, and return value. Given the tool's simplicity (3 optional params, no output schema, no annotations), it is sufficiently complete for basic use, though it could benefit from mention of related sibling tools or typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides the meaning of each parameter, including allowed values for asset_type and format for categories. Since schema coverage is 0%, this is the only source of parameter semantics and it does compensate reasonably, though defaults are not mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for Polyhaven assets with optional filtering, using a specific verb and resource. This distinguishes it from sibling tools like get_polyhaven_categories and download_polyhaven_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for searching assets but does not explicitly state when to use it versus alternatives like get_polyhaven_categories or search_sketchfab_models. No exclusions or alternative recommendations are provided, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a polling API, explains the return format (list of statuses or a single status), and details what each state means (done, in-progress, failed, canceled). This goes beyond a simple 'check status' by explaining how to interpret results and when to proceed.
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 structured into clear mode-specific sections, front-loading the purpose. It is somewhat verbose with repeated polling guidance, but every sentence contributes essential information and the structure aids readability.
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 two-mode complexity and absence of annotations or output schema, the description covers key aspects: purpose, parameters, return values, and how to interpret statuses. It could mention error handling or behavior when both parameters are supplied, but it is sufficiently complete for a status-checking 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 coverage is 0%, so the description must compensate. It explains that subscription_key is for MAIN_SITE and request_id for FAL_AI, both given from the generate model step. This adds meaningful context missing from the schema, though it doesn't clarify if both can be provided or constraints like formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a Hyper3D Rodin generation task is completed, with a specific verb 'check' and resource 'Hyper3D Rodin generation task'. It distinguishes between two modes (MAIN_SITE and FAL_AI), which differentiates it from sibling polling tools like poll_hunyuan_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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, including specifying which parameter to use for each mode and the polling semantics ('only proceed if the status are finally determined'). However, it does not explicitly mention alternatives or exclusion conditions, though the Rodin-specific context makes it obvious.
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/nludd25/blender-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nludd25/blender-mcp)

Score Badge

Copy to your README.md:

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

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