blender-mcp

Server Quality Checklist

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

Latest release: v1.6.0
Disambiguation3/5
Tools are mostly distinct by service (Polyhaven, Sketchfab, Hyper3D, Hunyuan3D), but there is overlap between generate_hyper3d_model_via_text/images and generate_hunyuan3d_model (which also accepts images). import_generated_asset is ambiguous because it doesn't specify the service, unlike import_generated_asset_hunyuan.
Naming Consistency3/5
Naming is predominantly verb_noun with snake_case, but there are inconsistencies: poll_rodin_job_status uses 'rodin' instead of 'hyper3d', import_generated_asset lacks a service qualifier, and set_texture is vague. The pattern is mostly readable but not uniformly applied.
Tool Count4/5
22 tools is on the higher end but appropriate given the server integrates four asset services (Polyhaven, Sketchfab, Hyper3D, Hunyuan3D) plus core scene inspection and code execution. Each integration requires status, search/download, generation, and polling tools, so the count is justified.
Completeness4/5
The tool surface covers the full asset pipeline lifecycle: search, preview, download, generate, poll, import, and status checks for each integration, plus scene/object info. Missing direct object manipulation tools (e.g., update/delete) are compensated by execute_blender_code, but dedicated tools would be more complete.
Average 3.9/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
- 13 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It notes a message is returned but fails to state whether the operation is read-only, has no side effects, or how errors are reported. This leaves the agent without a clear safety profile.
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 that immediately convey the core purpose and return behavior, with no redundant or filler content.
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?
Although the tool is simple, the lack of any explanation for the user_prompt parameter and the vague 'message' return leaves significant gaps. A minimal description should at least state whether the parameter is needed and what success/failure messages look like.
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 optional user_prompt parameter with no description, and the tool description does not mention it. At 0% schema coverage, the description should explain the parameter's role, but it remains 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 uses the specific verb 'Check' and identifies the exact resource 'Hunyuan3D integration' in Blender, clearly distinguishing this from sibling status tools like get_hyper3d_status. The return behavior is also stated ('Returns a message'), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/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 Hunyuan3D availability before using related features, but it does not explicitly state when to use it versus other status tools or how to react to the result. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that arbitrary code is executed, implying potential side effects, but it does not disclose safety risks, return behavior, persistence of changes, or error handling. The step-by-step hint implies long operations, but this is insufficient for a tool that can mutate Blender state.
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 very short and front-loaded with the main purpose. The second sentence is a practical tip, though it is somewhat vague. No extraneous information is present, but the tip could be more actionable. Overall, it earns a solid score for brevity and structure.
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?
Executing arbitrary code is a high-complexity operation, yet the description provides no information about expected outputs, error behavior, or side effects. There is no output schema, and the description does not compensate. It is incomplete for an agent to safely and effectively invoke this 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?
Schema description coverage is 0%, requiring the description to explain parameters. It does explain both parameters: 'code' is described as 'The Python code to execute' (minimal but accurate) and 'user_prompt' as 'the original user prompt ... for telemetry' (adds context). However, the descriptions are shallow and do not add much beyond parameter names, so they only barely compensate 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 the tool's function: 'Execute arbitrary Python code in Blender.' This is a specific verb+resource that distinguishes it from sibling tools, which are all focused on scene info, assets, or model generation. No other sibling tool executes code, so purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a practical guideline ('Make sure to do it step-by-step by breaking it into smaller chunks'), but it does not explicitly state when to use this tool versus alternatives. Since it's the only code-execution tool, the use context is implied, but there are no 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 provided, the description carries the full burden. It discloses that the tool returns a message about feature availability, which is useful, but it does not explicitly state that the operation is read-only or has no side effects. For a simple status check, 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 exactly two sentences, front-loaded with the primary action, and contains no wasted words. Every sentence earns its place, making it highly concise and well-structured.
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 complete absence of parameter documentation and only a vague mention of the return message leaves gaps. The description is sufficient for a basic status check, but it does not fully cover the input semantics or the exact output format, especially given that no output schema is provided.
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 input schema has one parameter (user_prompt) with no description, and schema description coverage is 0%. The description does not mention this parameter at all, leaving its purpose and expected value completely undocumented. This is a major gap that the description fails to compensate for.
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: checking whether PolyHaven integration is enabled in Blender. It uses a specific verb ('check') and resource ('PolyHaven integration'), distinguishing 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to verify PolyHaven availability, but it does not explicitly state when to use it versus alternatives or mention any prerequisites. The context is clear enough for a status check, but there is no explicit guidance on exclusions or when to prefer this tool over others.
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 disclosing behavior. It only states 'Returns a message indicating success or failure,' but omits side effects like scene modifications, file storage locations, network dependencies, or what happens on missing assets. The telemetry note about user_prompt is minor transparency but not behavioral.
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 single purpose sentence, a bulleted parameter list, and a one-line return note. Every element earns its place with no redundancy or filler.
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 basic purpose, parameters, and return behavior, but given that there are no annotations and no output schema, it misses critical context: when to use vs. alternatives, side effects on the Blender scene, error scenarios, and download/import details. It is minimally viable but has clear gaps for an agent to fully understand the tool's role.
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, so the description must compensate. It does so by explaining each parameter with examples: asset_type lists 'hdris, textures, models', resolution gives '1k, 2k, 4k', and file_format provides type-specific examples. This adds meaningful semantics beyond the raw schema, though it doesn't enumerate all possible values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Download and import a Polyhaven asset into Blender,' which uses a specific verb and resource, clearly distinguishing it from sibling tools like download_sketchfab_model or import_generated_asset. It leaves no ambiguity about what the tool does.
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 that it should be used after searching for a Polyhaven asset, nor does it contrast with Sketchfab or generated model tools. This lack of context makes it hard for an agent to decide when this tool is appropriate.
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 must carry the burden of behavioral disclosure. It does state the return type ('Returns the screenshot as an Image') and implies a read-only read of the viewport, but it does not explicitly mention lack of side effects or potential requirements like an open 3D viewport. 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 efficient and front-loaded with the main purpose. The parameter list is somewhat redundant with the schema but still adds useful detail. However, the inaccuracy regarding the default value prevents a perfect score, as every sentence should be accurate.
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 screenshot tool, the description covers the core action, parameters, and return type. But it lacks usage guidance, caveats about viewport availability, and has the default discrepancy. Given the lack of annotations and output schema, the description is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to both parameters (max_size and user_prompt), but it contains a factual error: it states max_size default is 800 while the schema says 1000. This contradiction makes the parameter information misleading. Despite explaining semantics, the error undermines reliability, so it does not sufficiently compensate 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 tool's function: 'Capture a screenshot of the current Blender 3D viewport.' This is a specific verb+resource combination that distinguishes it from siblings like get_scene_info or get_object_info, which provide textual information rather than visual capture.
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 should be used when a visual representation of the viewport is needed, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusions or prerequisites. The context is clear but there is no direct guidance on selection among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explicitly state that the tool is read-only, whether it requires an open Blender scene, or what side effects (if any) it has. The verb 'Get' implies read-only behavior, but this is not confirmed, and no return format or edge cases are mentioned.
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 and front-loaded with the main purpose, followed by a clear parameter list. It avoids unnecessary verbiage, though it could be slightly more structured (e.g., separating the main description from telemetry details), but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description is mostly adequate but leaves gaps. It fails to specify what 'detailed information' includes (e.g., object count, render settings) or any prerequisites like an active Blender scene. These omissions matter because there is no output schema to fill the void.
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?
Although the input schema provides only a title for 'user_prompt', the description adds valuable semantics by explaining it is the original user prompt required for telemetry. This compensates for the low schema description coverage (0%) and clarifies why the parameter is necessary.
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 ('Get') and resource ('detailed information about the current Blender scene'). It distinguishes itself from the sibling tool 'get_object_info' by targeting the scene as a whole rather than individual objects.
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 scene-level information is needed but does not explicitly state when to use this tool versus alternatives like get_object_info or execute_blender_code. No exclusions or alternative recommendations are provided, leaving usage largely implied.
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 must convey behavioral traits. It only states that it 'gets information,' which implies read-only, but it doesn't explicitly disclose that there are no side effects, error conditions, or permissions required. This is minimal disclosure beyond the basic action.
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 short paragraph that leads with the purpose and then lists parameter details. 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?
The description explains inputs but not what 'detailed information' includes or the return format, and it doesn't mention failure handling (e.g., missing object). Since there's no output schema, this gap leaves the agent uncertain about the tool's 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?
The input schema has no property descriptions (0% coverage), so the description compensates by explaining both parameters: object_name is the target object, and user_prompt is for telemetry. It adds meaning to user_prompt beyond the schema, though object_name's explanation is tautological.
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: retrieving detailed information about a specific object in the Blender scene. The verb 'Get' and the resource 'object' differentiate it from scene-level tools like get_scene_info or execute_blender_code.
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 object information is needed, but it does not explicitly mention alternatives or when not to use it. No exclusions or comparisons with sibling tools are provided, leaving the timing of use to inference.
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 fully disclose behavioral traits. It states that it returns a list of matching assets, but it does not explicitly mention that the operation is read-only, nor does it disclose potential rate limits, result count limits, or any side effects. This is a significant gap for a tool with no structured metadata.
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. Every sentence adds value, and the formatting aids readability.
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 essential aspects—purpose, parameters, and return type—but it is vague about what 'basic information' in the results includes. It also does not reference related tools (e.g., get_polyhaven_categories for category values or download_polyhaven_asset for obtaining full assets), which would make the context more 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 input schema has 0% description coverage, so the description compensates by explaining each parameter: asset_type with allowed values, categories as a comma-separated list, and user_prompt as telemetry. This is helpful, though it could be improved by providing examples of valid category values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Search') and resource ('assets on Polyhaven'), which is specific and distinguishes it from sibling tools like search_sketchfab_models that target a different platform.
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 usage context is implied by the tool's purpose—searching Polyhaven assets—but there is no explicit guidance on when to use this tool instead of alternatives, nor any mention of prerequisites or exclusionary cases.
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 behavioral disclosure burden. It adds that the tool returns a formatted list and that filtering is optional, but it doesn't disclose potential side effects (though likely none), sorting behavior, or any rate limits. The description adds some value beyond the schema but is 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 concise, with a clear one-line purpose statement followed by a list of parameters and their meanings. Every sentence adds value, and the structure 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 basic search functionality and parameter explanations, but it lacks information about the output format beyond 'formatted list', omits the user_prompt parameter, and provides no guidance on alternative tools. Given no output schema or annotations, more detail 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?
Schema description coverage is 0%, so the description must compensate. It explains the meanings of query, categories, count, and downloadable, including syntax (comma-separated list) and defaults. However, it omits the 'user_prompt' parameter entirely, leaving that parameter 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 searches for models on Sketchfab, with a specific verb ('search') and resource ('models on Sketchfab'). It also indicates the outcome by noting it returns a formatted list, distinguishing it from other tools like download_sketchfab_model or 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?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention alternative tools for other asset sources (e.g., search_polyhaven_assets) or conditions where this tool is 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, and the mention of 'for telemetry' for user_prompt discloses that user prompts are collected. However, it does not explicitly state that the operation is non-destructive, or any side effects, permissions, or rate limits.
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: one clear purpose sentence followed by a parameter list. Every sentence earns its place, with no redundant fluff, and it is appropriately sized for a simple 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 getter with no annotations, output schema, or complex parameters, the description is adequate but has gaps. It explains the tool's purpose and parameters, but does not describe the return format (e.g., whether categories are returned as a list of strings) or any potential errors or network dependencies.
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 input schema has no descriptions for the parameters, but the description provides explicit meaning: asset_type is explained with allowed values ('hdris, textures, models, all'), and user_prompt is described as 'The original user prompt that led to this tool call (for telemetry)'. 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 tool's function: 'Get a list of categories for a specific asset type on Polyhaven.' It uses a specific verb ('Get') and resource ('categories') with a scope ('for a specific asset type'), distinguishing it from sibling tools like search_polyhaven_assets which searches for assets, and download_polyhaven_asset which downloads 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?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It simply states what the tool does and lists parameters, leaving the agent to infer usage context.
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 burden of explaining behavior. It discloses that the tool performs a check and returns a message about feature availability, which is sufficient for a simple read-only status tool. It does not overpromise or hide 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 only two sentences, front-loaded with the core purpose, and every word adds value. It is succinct without sacrificing clarity.
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 main purpose and return type, but leaves the user_prompt parameter unexplained and provides no detail on possible output values or failure behavior. For a simple status tool this is adequate but incomplete, as the parameter gap remains unaddressed.
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 0% schema description coverage, and the description does not mention it at all. The parameter is left completely unexplained, and 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 specific action ('Check if Sketchfab integration is enabled in Blender') and the expected return ('a message indicating whether Sketchfab features are available'). It is unambiguous and distinct from sibling status tools for other services.
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 the tool is for verifying Sketchfab availability in Blender, giving clear context for use. It does not explicitly mention alternatives or exclusions, but the Sketchfab-specific wording and sibling list make the intended use obvious.
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 mentions the prerequisite and that a success/failure message is returned, but it does not disclose whether the operation overwrites existing textures, is reversible, or what errors may occur. 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 and well-structured: a single clear purpose statement followed by a parameter list and return value note. No redundant text.
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 setter tool, the description covers the essential workflow: the prerequisite of downloading, the parameters needed, and the return message. It lacks detail on failure modes or how object names are resolved, but the sibling tools provide enough context for the overall pipeline.
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 the two required parameters (object_name and texture_id) and adds the key constraint that the texture must be downloaded first. However, the optional user_prompt parameter is not mentioned, and with 0% schema coverage, the explanation is incomplete.
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: applying a previously downloaded Polyhaven texture to an object. It uses a specific verb ('apply') and resource ('texture to an object'), and it is distinct from sibling tools that download or search for assets.
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 conveys clear usage context by specifying 'previously downloaded' and noting in the parameter explanation that the texture must be downloaded first. It does not explicitly list alternative tools or when not to use, but the intended workflow is implied.
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 burden of explaining behavior. It clearly indicates this is a read-only check that returns a message about feature availability, which is sufficient for a simple status tool. It does not disclose potential error conditions or message format, but no mutation or side effects are implied.
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, directly front-loaded with the tool's purpose, and contains no redundant information. Every word earns its place, making it highly concise and well-structured.
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 with one optional parameter and no output schema, but the description is incomplete because it ignores the user_prompt parameter and gives only a vague notion of the return value ('a message'). While it covers the core purpose, the missing parameter explanation and lack of return format details leave gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter (user_prompt) with 0% description coverage, and the description does not mention or explain this parameter at all. This leaves the agent without any guidance on what user_prompt is for, despite it being present. The description fails to add meaning beyond the raw 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 checks if Hyper3D Rodin integration is enabled in Blender, using a specific verb ('check') and resource ('Hyper3D Rodin integration'). It also mentions the return value, making it distinct from sibling status tools for other integrations (e.g., get_polyhaven_status, 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 description provides clear context for when to use the tool: to verify whether Hyper3D Rodin features are available. It does not explicitly discuss alternatives, but the tool name and description make it obvious it's for Hyper3D Rodin only, and it is not for generation or other integrations.
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 full load. It discloses the return type (Image) and implies a read-only preview by saying 'before downloading'. However, it omits error behavior, rate limits, or explicit confirmation that no model data is downloaded, which is a moderate gap.
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 brief and well-structured: a one-sentence purpose, a usage sentence, a parameters list, and a return statement. Every sentence earns its place with no redundant content.
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 preview tool, the description covers the essential aspects: what it does, when to use it, the key parameter, and the return type. The main omissions are the undocumented 'user_prompt' parameter and lack of failure/error information, but given the simplicity and sibling context, it is largely 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 no descriptions (0% coverage), and the description compensates by explaining the required 'uid' parameter with context about its source. However, it entirely omits the 'user_prompt' parameter, leaving its purpose unexplained. This partial coverage prevents a higher 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 precisely states 'Get a preview thumbnail of a Sketchfab model by its UID', identifying the exact operation and resource. It also differentiates from sibling tools like download_sketchfab_model by clarifying its role in visual confirmation before download.
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 states when to use it: 'Use this to visually confirm a model before downloading.' It also tells the agent the UID originates from search_sketchfab_models, guiding the workflow. It does not explicitly list alternatives, but the usage context is clear.
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 burden. It discloses the scaling behavior ('largest dimension equals target_size'), return value ('message with import details including object names, dimensions, and bounding box'), and prerequisites ('must be downloadable and proper access rights'). It doesn't explicitly describe side effects on the Blender scene, but 'import' implies a create operation, which is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and efficiently explains scaling. The examples for target_size are helpful but slightly verbose. The parameter list omits user_prompt, which is a structural gap, but overall it's well-organized.
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 operation, scaling behavior, return format, and access prerequisites. It even gives sizing guidance. The lack of an explanation for user_prompt and no alternative pointers keep it from being a 5.
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 coverage is 0%, so the description must compensate. It does a great job on uid and target_size, including examples and units. However, it completely omits the third parameter, user_prompt, which is in the schema. This incomplete coverage prevents a higher 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 opens with 'Download and import a Sketchfab model by its UID,' which is a specific verb+resource pair. It clearly distinguishes itself from sibling tools like search_sketchfab_models and get_sketchfab_model_preview by focusing on the download/import action and the unique scaling-to-target-size behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: requires a UID, target_size, and proper access rights. It doesn't explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer when to use it (when a UID is available and the model is downloadable).
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 disclosure burden. It explicitly mentions the asynchronous workflow (returns job_id, status changes to DONE), import into Blender, built-in materials, and error messages. This goes beyond basic expectations, though it does not detail polling requirements 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: it starts with the primary action, then lists parameters, and finishes with return behavior. Every sentence provides value, and the structure is easy to parse for an AI agent.
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?
Covers the core workflow, input methods, and return format, which is good for an async generation tool. However, the omission of user_prompt and the ambiguous relationship to separate import/polling tools (e.g., import_generated_asset_hunyuan) leaves some context gaps. Without annotations or an output schema, the description does not fully resolve the complete operation flow.
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?
Adds meaningful descriptions for text_prompt (short English/Chinese description) and input_image_url (local/remote URL, accepts None). However, the schema's third parameter, user_prompt, is entirely omitted, and since schema description coverage is 0%, this missing parameter leaves a notable gap in understanding the full input interface.
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 via Hunyuan3D from text or image and imports it into Blender. This distinguishes it from sibling generation tools (e.g., Hyper3D) and import-only tools. The verb 'generate' and resource '3D asset using Hunyuan3D' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool: for Hunyuan3D generation with text, image, or both. However, it does not explicitly state alternatives or when not to use it, leaving some implicit differentiation from sibling tools like Hyper3D generation or separate 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 full responsibility. It discloses built-in materials, normalized size, and that it returns a success/failure message. It does not mention potential async behavior or side effects on the scene, but the core behavior is transparent enough.
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: two introductory sentences, a short parameter list, and a clear return statement. Every sentence adds value, and the parameter notes are directly useful.
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 main purpose, key parameters, and return type, but misses user_prompt semantics and any async or failure details. Given the complexity of a generation tool, it is adequate but not fully 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?
Schema coverage is 0%, so the description must compensate. It explains text_prompt must be in English and bbox_condition is an optional list of 3 floats controlling L/W/H ratio. However, it omits user_prompt entirely, leaving that parameter undocumented in both schema and description.
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 generates a 3D asset using Hyper3D from a text description and imports it into Blender. The 'via text' phrasing distinguishes it from the image-based sibling tool, so it scores high on purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: use a text description, the asset has built-in materials, and re-scaling may be needed after normalization. However, it does not explicitly contrast with alternative tools like image-based generation or mention when to prefer one over another.
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 a prerequisite ('after the generation task is completed') and the source of the URL, but does not mention side effects, reversibility, or failure modes. For a simple import tool, 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 concise, front-loaded with the core purpose, and uses a clean bullet list for parameters. Every sentence provides useful information without fluff or redundancy.
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 import tool, the description covers the action, the parameter semantics, and the return condition. It could mention the need to poll for job completion, but the phrase 'after the generation task is completed' implicitly covers this. Overall, it is complete enough given the tool's simplicity.
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 explain parameters. It does: 'name: The name of the object in scene' and 'zip_file_url: The zip_file_url given in the generate model step.' This adds meaning beyond the schema, clarifying the role of each parameter and their relationship to the workflow.
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 'Import the asset generated by Hunyuan3D after the generation task is completed,' using a specific verb ('Import'), a specific resource ('asset generated by Hunyuan3D'), and a clear context. It distinguishes itself from the sibling 'import_generated_asset' by naming Hunyuan3D in both the tool name and description.
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 it: 'after the generation task is completed' and refers to the 'zip_file_url given in the generate model step.' This provides clear contextual guidance, though it does not explicitly contrast with alternatives like the generic import_generated_asset or mention any 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 takes on the burden of disclosing behavior. It mentions that the asset has built-in materials, that the model has normalized size (which may require re-scaling), and that the tool returns a success/failure message. It also implies the side effect of importing into Blender. This is valuable context beyond the schema, though it could mention asynchronous behavior or potential scene modifications in more detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, behavioral notes, a parameter list, and a return statement. It is somewhat long but each sentence adds relevant information. The parameter details are organized and easy to scan. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of an output schema, the description provides a solid overview: purpose, key parameters, behavioral caveats, and return type. The main omission is user_prompt, which is part of the schema but unexplained. Overall, an agent can reasonably understand how to use the tool, though some edge cases (e.g., asynchronous behavior) are not covered.
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 detailed semantics for three of the four parameters: input_image_paths (absolute paths, wrap in list, required conditionally), input_image_urls (URLs, wrap in list), and bbox_condition (list of ints length 3, controls ratio). It does not explain user_prompt, which is a gap considering the schema has no descriptions and the description attempts to cover parameters.
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: generating a 3D asset via Hyper3D from images and importing it into Blender. It specifies the input (images) and 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?
Provides explicit guidance on when to use input_image_paths vs input_image_urls based on the current mode (MAIN_SITE vs FAL_AI). It clearly explains that only one input should be given, which clarifies usage conditions. However, it does not explicitly state when to choose this tool over alternatives like generate_hyper3d_model_via_text.
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 disclosure burden. It explicitly lists statuses ('DONE' and 'RUN'), mentions failure states, and explains the ResultFile3Ds field with the generated ZIP path. This covers the response structure adequately, though it doesn't enumerate all failure statuses.
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 repeats the same ResultFile3Ds information in two consecutive sentences ('If status is DONE...' and 'When the status is DONE...'), making it redundant. It also has minor grammatical errors. Still, the structure is clear with a parameter section and status explanation.
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 polling tool with one parameter and no output schema, the description provides necessary statuses, the result field, and polling guidance. It could mention the import sibling or possible error statuses, but it is sufficiently complete for an agent to use correctly.
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 only parameter, job_id, is described as 'The job_id given in the generate model step,' which directly links it to prior tool use. The schema provides no description (0% coverage), so this fills the gap completely.
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 'Check if the Hunyuan3D generation task is completed,' a specific verb+resource, and further clarifies it is a polling API. This distinguishes it from siblings like get_hunyuan3d_status by focusing on a specific job ID, not general service 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?
It instructs that job_id comes from the 'generate model step,' tying it to a preceding action. It also states 'This is a polling API, so only proceed if the status are finally determined,' giving clear guidance on when to stop polling. It doesn't explicitly name alternatives, but the reference to Hunyuan3D and job-specific polling is sufficient context.
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 discloses the two supported modes, the meaning of each status value, and the polling semantics. It doesn't mention rate limits or authentication, but for a read-only polling tool, the explanation of return statuses and when to proceed is sufficiently transparent.
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 two mode-specific sections, making the information easy to scan. Each sentence provides necessary detail about statuses and when to proceed. It's longer than a one-liner but the density of useful information justifies the length, 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?
Given the tool's moderate complexity (two modes, two parameters, no output schema), the description covers the main requirements: how to check completion, status interpretations, and the polling principle. The primary gap is that the response structure isn't explicitly described—for MAIN_SITE it says 'Returns a list of status' but doesn't specify if these are strings or objects, and for FAL_AI it says 'Returns the generation task status' without detailing the exact format.
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 no descriptions and both parameters are optional, so the description adds essential meaning. It explicitly links subscription_key to MAIN_SITE mode and request_id to FAL_AI mode, explaining they come from the generate model step. However, it doesn't specify the exact format or clarify which parameter is required in each mode, which is a minor 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 checks if a Hyper3D Rodin generation task is completed, with a specific verb (poll) and resource (Rodin job status). It distinguishes itself from sibling tools like get_hyper3d_status and poll_hunyuan_job_status by focusing on polling and specifying the two Rodin modes.
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 a generate step, to poll until the task reaches a final state. It explicitly states 'This is a polling API, so only proceed if the status are finally determined,' which gives actionable guidance. It doesn't explicitly name alternatives, but the mode-specific instructions and reference to the generate step make usage conditions clear.
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 exist, so the description carries the full burden. It discloses the expected return ('Return if the asset has been imported successfully') and a prerequisite (completion of generation). It does not detail potential side effects or error conditions, but for a simple import tool the key behavior is adequately disclosed.
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 purpose. Parameter details are presented in a clean bulleted list with no redundant information. Every sentence adds value, and the return behavior is communicated in a single short sentence.
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, the description covers purpose, parameters, usage prerequisites, and return value. It does not mention error handling if both task_uuid and request_id are provided or neither, which is a minor gap, but overall it is sufficient for correct invocation.
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 coverage is 0%, so the description is essential. It explains all three parameters: `name` (object in scene), `task_uuid` (for MAIN_SITE mode), and `request_id` (for FAL_AI mode), including the exclusivity constraint. 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 a specific verb ('Import') and a specific resource ('the asset generated by Hyper3D Rodin'). It distinguishes from the sibling tool `import_generated_asset_hunyuan` by explicitly naming the source system, and the purpose is unique among siblings.
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 states when to use the tool ('after the generation task is completed') and provides a critical usage rule ('Only give one of {task_uuid, request_id} based on the Hyper3D Rodin Mode'). While it does not explicitly contrast with alternative tools, the mode-specific guidance is clear and actionable.
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:

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

Score Badge

Copy to your README.md:

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

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