BlenderMCP

Server Quality Checklist

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

Latest release: v1.5.5
Disambiguation4/5
Most tools have clearly distinct purposes (search vs. download vs. preview), but some pairs like import_generated_asset and import_generated_asset_hunyuan could be confused without careful reading. The generate tools for Hyper3D and Hunyuan both accept text prompts, though provider names distinguish them.
Naming Consistency3/5
Naming generally follows a verb_noun pattern, but there are inconsistencies: 'generate_hyper3d_model_via_text' vs. 'generate_hunyuan3d_model', 'poll_rodin_job_status' vs. 'poll_hunyuan_job_status', and 'import_generated_asset' vs. 'import_generated_asset_hunyuan'. Also 'get_hunyuan3d_status' uses 'hunyuan3d' while other Hunyuan tools use 'hunyuan'.
Tool Count4/5
At 22 tools, the server is on the heavier side but the count is justified by covering multiple integrations (Polyhaven, Sketchfab, Hyper3D, Hunyuan3D) plus scene utilities. Each integration has a clear lifecycle (status, search/generate, poll, import), so no tool feels redundant.
Completeness4/5
The asset workflows are well covered: search, preview, download, generate, poll, import, and apply textures. The main gap is general Blender object manipulation, but the execute_blender_code tool fills that gap, and the server appears focused on asset integration rather than full scene editing.
Average 4/5 across 22 of 22 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.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

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. The verb 'Get' implies a read-only operation, but it does not explicitly state that it is non-destructive, what happens if no scene is open, or any details about the return format. This is minimal but acceptable for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no wasted words. It is front-loaded with the action and target, making it easy to process.
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?
There is no output schema, so the description must explain what information is returned, but it only says 'detailed information' without specifying any fields or structure. Given the simple nature of the tool, this vagueness leaves the agent uncertain about what to expect, making the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty properties). The description correctly adds nothing about parameters since none exist. Baseline for 0 params is 4, and the description meets that.
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 with a specific verb ('Get') and resource ('detailed information about the current Blender scene'). It distinguishes itself from siblings like get_object_info (focused on a specific object) and get_viewport_screenshot (returns an image), though it does not enumerate what 'detailed information' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention contexts where scene-level info is needed or where get_object_info would be more appropriate, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention potential side effects, irreversibility, error handling, or the fact that code runs in Blender's context and can mutate scenes—critical information for a tool that executes arbitrary code.
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 exceptionally concise, with the main purpose in a single sentence and one useful procedural note. It is front-loaded and contains 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?
For a tool that executes arbitrary code, the description is insufficient. It omits return values, output behavior, error handling, and side effects, and there is no output schema or annotations to fill these gaps. The procedural note is helpful but does not make the description 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 description defines the 'code' parameter as 'The Python code to execute,' which adds minimal meaning beyond the schema's title 'Code.' It does not clarify expected format, length, or execution constraints, but it does at least explain the parameter's purpose.
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 'Execute arbitrary Python code in Blender,' which is a specific verb+resource combination that clearly differentiates it from sibling tools focused on asset generation, status checks, and scene information.
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 instruction to 'do it step-by-step by breaking it into smaller chunks' provides procedural guidance but does not explicitly state when to use this tool versus alternatives or when not to use it. The use case is implied rather than clearly articulated.
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. It only restates the basic function of fetching categories and does not disclose behavioral traits like network dependence, return format, pagination, or error handling.
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: one sentence for purpose and a brief parameter list. No filler or redundant content since the schema lacks 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?
The tool is simple, but with no annotations or output schema, the description could mention the response format or note that it involves a network call. It is minimally adequate, but lacks some context that would help an agent anticipate failure modes or return data.
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% (the schema only has the property name 'Asset Type'), so the description must compensate. It lists the parameter (asset_type) and enumerates its valid values ('hdris, textures, models, all'), which adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a list of categories for a specific asset type on Polyhaven, using a specific verb 'get' and a clear resource. This distinguishes it from sibling tools like search_polyhaven_assets or 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as search_polyhaven_assets or get_polyhaven_status. The description does not mention prerequisites, typical workflows, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the statuses (DONE, RUN), the ResultFile3Ds field on success, and the polling nature. However, it only vaguely references 'some failed state' and lacks details on error handling, invalid job IDs, or the safety of repeated calls.
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 a clear purpose but suffers from redundancy: the ResultFile3Ds content is described twice in almost identical terms. A more concise single explanation would improve it. The structure with a parameters list is helpful, but the repetition detracts.
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 there is no output schema, the description appropriately explains return values (status and ResultFile3Ds). However, it is incomplete in covering failure states ('some failed state' is vague) and does not address edge cases like invalid job_id or behavior on unexpected responses. For a polling tool, more explicit guidance on final states 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 provides job_id with no description, and the context notes 0% schema description coverage. The description compensates by explaining job_id is 'the job_id given in the generate model step', which gives clear provenance and usage. This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Check if the Hunyuan3D generation task is completed', with a specific verb and resource. It also differentiates from other poll tools (e.g., poll_rodin_job_status) by specifying Hunyuan3D, but does not explicitly contrast with the sibling get_hunyuan3d_status, so it lacks full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates that job_id comes from the generate model step and that this is a polling API to be used until a final status (DONE or failed) is reached. This provides clear usage context, though it does not explicitly state when not to use this tool or mention alternatives.
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 transparency burden. It only states that the tool 'returns a list of matching assets with basic information,' but does not disclose read-only nature, limitations, failure modes, network behavior, or output shape beyond a vague list.
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, front-loaded with purpose, and includes a clean parameter list followed by a return statement. Every sentence earns its place with no redundant or irrelevant text.
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 the tool being named 'search,' no query/text parameter exists, and the description does not clarify that search is performed only via asset_type/category filters. It also does not specify what 'basic information' includes, and with no output schema, the agent cannot predict the result structure adequately.
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 adds critical semantics absent from the input schema: exact allowed values for asset_type (hdris, textures, models, all) and the comma-separated format for categories. Since schema description coverage is 0%, this compensation is essential and effective.
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 'Search for assets on Polyhaven with optional filtering,' clearly identifying the verb and resource. It distinguishes itself from sibling tools like download_polyhaven_asset and get_polyhaven_categories by explicitly focusing on searching assets.
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 searching Polyhaven assets, but it does not explicitly state when to prefer this over sibling search tools (e.g., search_sketchfab_models) or related category/download tools. No exclusions or alternative guidance is provided, leaving usage context inferred rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does mention that the tool imports into Blender and returns a success/failure message, but it does not disclose potential side effects like scene overwrites, network requirements, or whether the operation is reversible.
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: a two-sentence overview, a compact parameter list, and a return note. Every line adds value and there is no filler or redundant phrasing.
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 4-parameter tool with no output schema, the description covers the key elements: purpose, all parameters with examples, optionality, and the return type. It lacks exact allowed values and error scenarios, but overall it provides enough context for an agent to invoke the tool correctly in most cases.
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%, but the description compensates by explicitly documenting all four parameters with concrete examples (hdris/textures/models, 1k/2k/4k, hdr/exr/jpg/png/gltf/fbx) and marks file_format as optional. It could enumerate exact allowed values, but it adds substantial meaning beyond the bare 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 verb+resource+destination: 'Download and import a Polyhaven asset into Blender.' This clearly distinguishes the tool from sibling download tools (e.g., download_sketchfab_model) and search tools (e.g., search_polyhaven_assets).
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 given on when to choose this tool over alternatives, when it is appropriate to use, or what prerequisites exist (e.g., searching first, Blender being open). The description simply states the action without contextual framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It says 'Get' which hints at read-only, but it does not clarify what information is returned, how errors are handled (e.g., object not found), or whether there are side effects. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and a parameter list. Every part earns its place, and the structure is clean and immediately readable. There is no fluff or redundant 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 minimal schema (1 param), no output schema, and no annotations. The description only says 'detailed information' without specifying which details (transforms, materials, mesh data, etc.) are included. For a getter tool, this is insufficient for an agent to know what to expect from the response, especially without an 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?
The description includes 'object_name: The name of the object to get information about', which clarifies the parameter's role beyond the schema's bare title 'Object Name'. While the addition is minimal, it explicitly ties the parameter to the tool's purpose, making it useful for the agent.
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 detailed information about a specific object in the Blender scene. The verb 'Get' + resource 'specific object' makes the purpose unambiguous and distinguishes it from siblings like get_scene_info (scene-level) and get_viewport_screenshot (visual).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need details about a single object. However, it does not explicitly compare with alternatives (e.g., get_scene_info for scene-level data) or state prerequisites like 'object must exist'. The context is clear enough for an agent to decide, but lacks explicit exclusions.
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 tool returns a message and includes a unique behavioral instruction about not emphasizing the key type in the response. This goes beyond typical structured data, though it is somewhat cryptic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with only two sentences, but the typo 'sliently' and the vague 'key type' phrase slightly undermine clarity. Still, it is largely concise 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 status check with zero parameters and no output schema, the description provides adequate context: it explains the tool's purpose and the nature of the return message. It could mention possible response values, but this is not critical for such a 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?
There are zero parameters, so the schema trivially covers everything. The description adds no param semantics, but none are needed. Baseline 4 applies for zero-parameter tools.
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 with a specific verb (Check) and resource (Hyper3D Rodin integration in Blender). It distinguishes itself from sibling status tools like get_hunyuan3d_status by explicitly naming the targeted 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?
No guidance is provided on when to use this tool versus alternatives. Sibling tools such as get_hunyuan3d_status serve similar status-checking roles, but the description does not mention any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the operation (capture) and return type (Image), which implies a read-only, non-destructive action. However, it does not explicitly disclose side effects, requirements (e.g., an active viewport), or error behavior, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very compact: one action sentence, a parameter list, and a return statement. Every word earns its place with no redundancy, and the key info 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?
For a simple tool with one optional parameter and no output schema, the description covers the action, parameter, and return type. It is slightly thin on edge cases or limitations, but sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter max_size is fully explained in the description: 'Maximum size in pixels for the largest dimension (default: 800).' This adds meaning beyond the bare schema property, clarifying the unit and which dimension it constrains.
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 verb and resource: 'Capture a screenshot of the current Blender 3D viewport.' This clearly distinguishes it from sibling tools like get_scene_info or asset import tools. The scope ('current') and output ('Image') are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The description simply states what it does; it does not mention contexts where it is appropriate or where another tool might be preferred.
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 does disclose the scaling behavior (largest dimension equals target_size) and the return message content (object names, dimensions, bounding box), and warns about downloadability/access rights. However, it does not mention potential side effects (e.g., adding to current scene, overwriting), error behavior, or whether the operation is synchronous. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear one-sentence purpose followed by parameter details and examples. The parameter section is slightly redundant with the schema, but it adds valuable context and examples. It is not overly verbose, earning a high score, though it could be trimmed for tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and minimal annotations, the description covers the return value (message with object names, dimensions, bounding box) and the scaling behavior. It also mentions prerequisites (model must be downloadable, access rights). It could be more complete by mentioning failure modes or that the model is imported into the current Blender scene, but overall it is sufficiently complete for common use cases.
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?
Despite the schema having no descriptions (0% coverage), the description provides detailed semantics for both parameters. It explains uid as 'unique identifier' and target_size as 'target size in Blender units/meters for the largest dimension,' with multiple real-world examples. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Download and import a Sketchfab model by its UID.' It specifies the resource (Sketchfab model) and the method (by UID), which is distinct from sibling tools like search_sketchfab_models or download_polyhaven_asset. This is a specific verb+resource+method formulation.
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: you need a UID and must specify target_size, with examples for common objects. It notes access rights must exist. However, it does not explicitly state when to prefer this tool over alternatives like get_sketchfab_model_preview or search_sketchfab_models, nor does it provide exclusions or alternative tool references. This is implied usage but not fully explicit.
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, but does not clarify whether it checks a setting or makes a network call, nor does it describe error behavior or safety profile. Basic transparency, 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 exactly two sentences, front-loaded with the primary action, and contains no unnecessary words. It is concise and well-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?
For a simple zero-param status check, the description is adequate: it states what it does and what it returns. However, it lacks specifics about the format of the message or how to interpret 'enabled' versus 'disabled', which could be useful in edge cases. Not a full 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description correctly implies no inputs are needed, and there is no parameter information to supplement.
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 PolyHaven integration is enabled in Blender, using a specific verb ('check') and resource ('PolyHaven integration'). It distinguishes itself from sibling tools like search_polyhaven_assets and other integration status tools by naming PolyHaven explicitly.
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 precondition before using PolyHaven features, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. No mention of 'use before downloading assets' or similar guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a message indicating availability, which adds context beyond the name. However, it doesn't mention potential side effects, network requirements, or error scenarios, though for a read-only status check this is less critical.
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 totaling 24 words, with no redundant information. It is concise, focused, and every word contributes to clarifying purpose and output.
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 no-parameter status checker, the description adequately covers what the tool does and what it returns. It lacks detail on output message format or error conditions, but given the tool's simplicity and absence of output schema, 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 tool has zero parameters, so the schema fully covers the input. The description adds no parameter-specific details, but with no parameters, the baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if Sketchfab integration is enabled, using the specific verb 'Check' and resource 'Sketchfab integration in Blender'. It distinguishes itself from sibling status tools by naming the specific integration, so there is no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to verify Sketchfab availability but does not explicitly discuss when to use it versus alternatives like get_polyhaven_status. There is no exclusion or alternative guidance, but the use case is straightforward enough that the implication is sufficient.
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 of disclosure. It only mentions 'Returns a message indicating success or failure' but does not disclose that the tool modifies the object's material, whether it replaces existing textures, or any error conditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear action sentence, a structured parameter list, and a return message. Every sentence serves a purpose with no redundancy or fluff.
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 2-parameter tool with no output schema, the description covers purpose, parameters, and return message. It clearly implies the dependency on downloading, but does not detail error scenarios or side effects beyond success/failure, leaving a minor gap.
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 provides no descriptions (0% coverage), so the description adds meaning for both parameters. object_name is defined as 'Name of the object to apply the texture to' and texture_id as 'ID of the Polyhaven texture to apply (must be downloaded first)'. This effectively compensates for the schema 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 'Apply a previously downloaded Polyhaven texture to an object', using a specific verb and resource. It distinguishes itself from sibling tools like download_polyhaven_asset by focusing on applying rather than downloading.
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 phrase 'previously downloaded' provides clear context that a download must precede use, implying the dependency on download_polyhaven_asset. However, it does not explicitly name alternative tools or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explains the asynchronous nature (job_id, status DONE), the import side-effect into Blender, and the built-in material property, all of which go beyond the basic schema.
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 succinct purpose sentence followed by parameter and return sections. It is slightly longer than necessary but every part adds useful information without excessive verbosity.
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 async job flow, return format, import behavior, and materials, which is sufficient given no output schema. Minor gaps like prerequisites or specific failure reasons exist, but overall it is complete enough for an agent to invoke and interpret the result.
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%, but the description compensates by explaining text_prompt as a short English/Chinese description and input_image_url as a local/remote URL that accepts None when text-only. This adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 3D asset using Hunyuan3D from text or image and imports it into Blender. This distinguishes it from sibling tools like generate_hyper3d_model_via_text or separate status/import tools.
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 when to use the tool (generation from text/image) but provides no explicit guidance on when not to use it or how it compares to alternatives such as generate_hyper3d_model_via_text or generate_hyper3d_model_via_images. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It states the return behavior ('Return if the asset has been imported successfully') and the prerequisite, but lacks details on side effects, failure handling, or permission requirements. Some context is added, but not comprehensive for an import 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 concise: a one-line purpose, a structured parameter list, and a return note. No unnecessary words or repetition. Well organized and front-loaded.
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 2-parameter tool, the description covers the basics: purpose, trigger condition, parameter meanings, and return value. However, it omits guidance on error conditions or integration with polling tools (e.g., get_hunyuan3d_status) to ensure the generation task is actually done. Given no annotations or output schema, this is a notable gap.
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 only types with no descriptions (0% coverage). The description compensates by explaining both params: 'name: The name of the object in scene' and 'zip_file_url: The zip_file_url given in the generate model step.' This adds meaningful context beyond field names.
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 Hunyuan3D after the generation task is completed.' It uses a specific verb ('Import') and resource ('generated asset from Hunyuan3D'), distinguishing it from the sibling 'import_generated_asset' which likely handles other 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 clear when-to-use context: 'after the generation task is completed' and references 'the zip_file_url given in the generate model step.' It implicitly links to generate_hunyuan3d_model and poll_hunyuan_job_status, but does not explicitly exclude alternatives like import_generated_asset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly discloses return behavior, status values per mode, failure conditions, and the polling rule. This is excellent transparency for a status-checking tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized by mode and front-loaded with the purpose, but it repeats the polling instruction almost verbatim for both modes. This redundancy makes it less concise than it could be, though it remains scannable.
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 two-mode polling tool with no output schema and no annotations, the description covers parameters, status values, and completion semantics for both modes. It omits edge cases like error handling or retry timing, but these are not essential for a basic status check.
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 two undocumented parameters (0% coverage). The description compensates by explaining that subscription_key and request_id come from the generate step and mapping each to the appropriate mode. It doesn't explicitly state that exactly one is required or that they are mode-specific, but it adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether a Hyper3D Rodin generation task is completed, with specific verb 'Check if' and resource. However, it doesn't explicitly differentiate itself from similar status tools like get_hyper3d_status, so it's clear but not fully distinguished.
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 usage context: it is a polling API to use after a generate step, and it instructs when to proceed (only when status is final). It does not mention alternatives or exclusions, but the context is strong enough for an agent to know when to call it.
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 disclosing behavior. It states that it returns a formatted list and mentions the default for 'downloadable,' but it does not describe authentication, network behavior, or other side effects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and then lists parameters with definitions. It is reasonably concise, though the parameter list repeats some names and defaults from the schema while adding explanations. Overall, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema, no annotations), the description covers the essential aspects: purpose, all parameters with defaults, and the return type ('formatted list'). It is complete enough for an agent to select and invoke the tool correctly, though it could be slightly more specific about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, but the description compensates fully by explaining each parameter's meaning: query is text, categories is a comma-separated optional list, count is a maximum with a default, and downloadable filters to downloadable models. This goes well beyond the schema's type/default information.
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 'Search for models on Sketchfab with optional filtering,' which is a specific verb+resource combination. It clearly distinguishes this tool from siblings like download_sketchfab_model and search_polyhaven_assets by platform and action.
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 establishes a clear context: use this when you need to search for Sketchfab models. It does not explicitly mention when not to use it or name alternatives, but the platform-specific wording and sibling list make the intended usage obvious.
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 of behavioral disclosure. It indicates that the tool is a read-only check that returns a message, and it additionally discloses a subtle behavior: not emphasizing the key type and silently remembering it. This goes beyond a minimal description, though the 'key type' detail is cryptic.
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 front-loaded, with the core purpose in the first sentence. Every sentence adds either return-value information or a special handling instruction, and no words are wasted.
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 with no output schema, the description does state that a message is returned and that it indicates availability. However, it does not specify possible status values or explain the ambiguous 'key type' instruction, leaving some minor gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so no additional parameter documentation is needed. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and a clear resource 'Hunyuan3D integration', which distinguishes it from sibling status tools like get_hyper3d_status and get_polyhaven_status. It states exactly what it checks and what it returns.
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 frames the tool as an integration availability check, implying it is used to verify feature availability before using Hunyuan3D generation tools. It does not explicitly name alternatives or exclusions, but the intended context is unambiguous.
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 transparency burden. It adds useful context about the parameter exclusivity and the return value ('Return if the asset has been imported successfully'). However, it does not disclose potential side effects like scene mutation, name conflicts, or failure modes, so transparency is incomplete.
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 well-structured with a clear purpose line, a concise parameter list, a warning, and a return statement. Every sentence adds necessary information without redundancy or filler.
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 output schema, the description covers the core aspects: what it does, when to use it, parameter semantics, and return status. It lacks error-handling details but is reasonably complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema offers only types and defaults (0% coverage), but the description thoroughly explains each parameter: 'name' as the scene object name, 'task_uuid' for MAIN_SITE mode, 'request_id' for FAL_AI mode, and the rule to supply only one. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Import the asset generated by Hyper3D Rodin after the generation task is completed.' It clearly states the tool's function and distinguishes it from the sibling tool import_generated_asset_hunyuan by specifying the Hyper3D Rodin 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 explicit timing context ('after the generation task is completed') and a clear selection rule for parameters: 'Only give one of {task_uuid, request_id} based on the Hyper3D Rodin Mode!' This gives practical when-to-use guidance, though it does not explicitly contrast with alternative import tools.
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 model has built-in materials, normalized size (making re-scaling useful), and that the tool imports the asset into Blender. It also notes the return message, providing useful behavioral context beyond just 'generate'.
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 first sentence for purpose, followed by behavioral notes and parameter details. It's slightly verbose but every sentence contributes useful information, and the parameter list is organized for 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 3 parameters, no annotations, and no output schema, the description covers the essential details: what it does, parameters and their conditions, behavioral traits, and return value. It does not mention async behavior or how to poll status, which might be relevant given sibling tools, but overall it is sufficiently complete for a competent agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by explaining each parameter in detail: absolute paths, list wrapping, mode requirements, mutual exclusivity, and bbox_condition format (list of 3 ints controlling ratio). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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+action distinguishes it from sibling tools like generate_hyper3d_model_via_text.
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 explicitly explains when to use input_image_paths vs input_image_urls based on Hyper3D Rodin's mode, and that only one should be given at a time. However, it does not explicitly state when to prefer this tool over text-based generation or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses useful behavioral traits: the asset has built-in materials, a normalized size (suggesting re-scaling may be needed), and it returns a success/failure message. This goes beyond a bare functional statement.
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 organized: a clear purpose sentence, two concise behavioral notes, a parameter list with explanations, and a return-value line. Every sentence adds value with no redundant filler.
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?
With only two parameters, no output schema, and no annotations, the description covers the essential invocation needs: what the tool does, parameter constraints, and expected return. It could mention whether the generation is asynchronous, but the success/failure message is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types (string, array of numbers), while the description adds essential meaning: text_prompt must be in English, and bbox_condition is optional but must be a list of three floats controlling the Length/Width/Height ratio. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Generate 3D asset using Hyper3D by giving description of the desired asset, and import the asset into Blender.' This specifies a precise verb, resource, and outcome, distinguishing it from siblings like generate_hyper3d_model_via_images or generate_hunyuan3d_model.
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: use this tool when you have a text description to generate a 3D asset and bring it into Blender. It does not explicitly name alternatives or exclusions, but the context is unambiguous given the tool's name and description.
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 explicitly states that the tool returns a thumbnail as an Image, which is a clear behavioral trait. It also implies a read-only preview action ('preview'), and the 'before downloading' context suggests it does not trigger a full-model download, adding useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a clear usage hint, a parameter definition, and a return description. Every sentence adds value, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is complete: it explains the purpose, when to use it, what the parameter means, and what the return value is. It also connects to sibling tools (search_sketchfab_models) appropriately, making it fully self-contained for an agent.
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 only the parameter name 'uid' with no description (coverage 0%). The description adds meaningful semantics by explaining that uid is 'the unique identifier of the Sketchfab model (obtained from search_sketchfab_models)', which tells the agent where the value comes from, thus compensating for the lack of schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a preview thumbnail of a Sketchfab model by its UID', which specifies the exact action and resource. It distinguishes itself from sibling tools like download_sketchfab_model and search_sketchfab_models by focusing on the preview/thumbnail functionality.
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: 'Use this to visually confirm a model before downloading.' This implies it is a pre-download verification step, distinguishing it from the actual download tool, though it does not explicitly list when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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