blender-mcp

Server Quality Checklist

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

Latest release: v1.6.0
Disambiguation4/5
Tools for each service (Polyhaven, Sketchfab, Hunyuan3D, Hyper3D) are clearly separated with distinct actions like search, download, generate, poll, and import. However, multiple generate/poll/import pairs for different AI services could cause some confusion if the agent doesn't read descriptions carefully.
Naming Consistency4/5
Most tools follow a verb_noun snake_case pattern (e.g., download_polyhaven_asset, execute_blender_code). There are minor inconsistencies like 'generate_hunyuan3d_model' vs 'generate_hyper3d_model_via_images' and the use of 'poll_' vs 'get_' for status checks, but overall patterns are predictable.
Tool Count4/5
22 tools is slightly on the higher side but reasonable given the integration of multiple external services (2 asset libraries, 2 AI generation APIs) and core Blender operations. Each tool has a specific purpose and no tool appears redundant.
Completeness4/5
The server covers asset acquisition (download from Polyhaven/Sketchfab, AI generation), scene info, texture application, viewport capture, and arbitrary code execution. Missing are direct object manipulation tools, but execute_blender_code can compensate. Minor gap: no tool for listing or creating basic primitives.
Average 3.5/5 across 22 of 22 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 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?
No annotations are provided, so the description carries full burden. It mentions a returned message but does not describe the message format, possible values (e.g., enabled/disabled), or whether any state changes occur. No side effects or permissions are disclosed.
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?
Two sentences, no wasted words. Could be improved by using bullet points or grouping, but is very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the existence of many sibling status-checking tools, the description lacks detail about what 'enabled' means, the role of 'user_prompt', and the expected return value. No output schema, so return format is unspecified.
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 parameter 'user_prompt' with default '' and no description. The tool description does not mention this parameter at all, adding no meaning beyond the schema. With 0% schema coverage, the description should compensate but fails completely.
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 it checks if Sketchfab integration is enabled, with a specific verb and resource. It distinguishes from siblings like get_polyhaven_status by naming Sketchfab, but does not elaborate on what 'enabled' means or how the result is presented.
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 on when to use this tool vs alternatives like get_hunyuan3d_status or when not to use. No context about prerequisites or typical scenarios is provided.
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 bear the full burden of transparency. While it implies a read-only check, it does not explicitly state the absence of side effects, required permissions, or what the 'message' contains.
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 short (two sentences) and front-loaded with the main purpose. However, it could be slightly more concise by combining sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and any explanation of the parameter, the description is woefully incomplete. It does not clarify return values, parameter semantics, or operational constraints.
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 0% schema description coverage. The description completely ignores this parameter, failing to explain its meaning or how it affects the tool's behavior.
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 verb 'Check' and the resource 'PolyHaven integration enabled status' in Blender. It effectively distinguishes from sibling tools like download_polyhaven_asset or get_polyhaven_categories.
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. Siblings like get_sketchfab_status or get_hunyuan3d_status serve similar purposes but receive no differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. Only states it returns a formatted list, but lacks details on pagination, rate limits, data freshness, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and to the point, uses a clear list for parameters. Could be slightly more structured but is efficient 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?
Adequately describes core parameters and return type, but lacks details on valid categories, filtering behavior, and edge cases. Missing output schema increases need for completeness.
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 meaning for 4 of 5 parameters (query, categories, count, downloadable) beyond schema, but misses user_prompt. With 0% schema coverage, description partially compensates.
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?
Clearly states it searches for models on Sketchfab with optional filtering. Differentiates from sibling tools by specifying the platform (Sketchfab vs Polyhaven).
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 on when to use this tool vs alternatives like download_sketchfab_model or search_polyhaven_assets. Does not mention prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions returning a message but does not specify the message format, possible values (e.g., true/false or detailed status), or any side effects. Lacks details on what determines 'enabled'.
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?
Two sentences, no fluff. However, conciseness sacrifices necessary detail. Still earns a high score for efficiency.
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 (one optional param, no output schema), the description is adequate but not thorough. It fails to describe the return value structure, potential errors, or how to interpret the message, leaving gaps for an AI agent.
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 only parameter 'user_prompt' has no description in the schema and the tool description does not explain its purpose or effect. With 0% schema description coverage, the description adds no value for parameter understanding.
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 Hunyuan3D integration is enabled in Blender, using specific verb 'Check' and resource 'Hunyuan3D integration'. It distinguishes itself from sibling tools like generate_hunyuan3d_model or poll_hunyuan_job_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It implies usage before generating Hunyuan3D models but does not provide when-not examples or prerequisites like needing the integration to be installed.
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 should disclose behavioral traits. It only states the basic action, without mentioning that the tool is read-only, any rate limits, or authentication requirements. The description is insufficient for safety-critical decisions.
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 single introductory sentence followed by a parameter list. Every sentence provides necessary information without redundancy. It is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not specify the return format or structure (e.g., list of strings, objects). For a simple listing tool, the description should at least indicate what the response contains. This omission limits the agent's ability to process results.
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 compensates by listing valid values for asset_type ('hdris, textures, models, all') and clarifying that user_prompt is for telemetry. This adds meaning beyond the schema's default values and names.
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 retrieves categories for a specific asset type on Polyhaven. It uses a specific verb ('Get') and resource ('categories'). Distinguishing from sibling tools like search_polyhaven_assets is implied but not explicit; the tool focuses on categories not 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 provided on when to use this tool versus alternatives such as search_polyhaven_assets. There is no mention of prerequisites, context, or exclusion criteria. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the zip_file_url comes from a prior step and that the tool returns a success indicator, but does not disclose side effects, permissions, or overwrite behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences and a parameter list. It is front-loaded with the main purpose. However, it could be slightly more structured (e.g., separating behavior from parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, the description fails to define what 'successfully imported' means (e.g., return value type), error conditions, or behavior when asset already exists. Incomplete for a tool with no annotations.
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?
Schema description coverage is 0%. The description explains 'zip_file_url' as coming from the generate step, but provides no additional meaning for 'name' or details on format, uniqueness, or constraints. Incomplete parameter guidance for a tool with 2 required params.
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 imports an asset generated by Hunyuan3D after the generation task completes. It uses specific verb 'Import' and resource 'asset generated by Hunyuan3D', distinguishing it from siblings like 'import_generated_asset' and '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 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 after the generation task is completed, but does not explicitly state when or when not to use it, nor does it mention alternatives. Usage context is implied but not fully clarified.
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, description carries full burden but only mentions success/failure. Missing details on blocking behavior, overwrite semantics, error cases, or side effects on Blender scene.
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?
Front-loaded purpose, then lists parameters. No fluff, but telemetry parameter description feels slightly out of place. Concise overall.
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?
Parameters are explained but behavioral aspects (import process, error handling) are absent. Output schema not provided, but description says 'returns message indicating success or failure', which is adequate.
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 description compensates by listing parameters with examples (asset_type options, resolution common values, file_format per type). Adds meaning beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (download and import), resource (Polyhaven asset), and context (into Blender). Distinguishes from sibling download_sketchfab_model by specifying Polyhaven.
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 on when to use this tool versus alternatives like search_polyhaven_assets or download_sketchfab_model. No explicit when/when-not criteria.
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 behavioral burden. It discloses async operation (job_id returned, status changes to DONE), import into Blender, built-in materials, and error returns. However, it omits rate limits, auth requirements, and explicit confirmation of mutation vs read. The coverage is moderate.
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 relatively concise but includes parameter descriptions that partially overlap with schema info. The structure is clear: purpose, params, returns. Some details could be more streamlined.
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 complexity of 3D generation and sibling tools like get_hunyuan3d_status, the description covers async behavior but fails to reference how to track progress or handle failures. It also lacks an output schema. 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It covers text_prompt and input_image_url adequately but completely omits the user_prompt parameter that appears in the schema. This leaves a parameter undocumented, which is a significant 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 it generates a 3D asset using Hunyuan3D from text or image input and imports into Blender. This distinguishes it from siblings like download_polyhaven_asset (downloads existing assets) and generate_hyper3d_model_via_text (different service), providing a specific verb and resource.
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 explains when to use (text, image, or both) but lacks explicit guidance on when not to use this tool vs alternatives like generate_hyper3d_model_via_text. No comparisons or prerequisites are mentioned, making it adequate but not exemplary.
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 exist, so the description must fully disclose behavior. It only says 'Get detailed information' without explaining what information is returned, whether it is read-only, or any side effects. This is insufficient for safe agent invocation.
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 (two sentences plus parameter details) and front-loaded with purpose. Every sentence adds value, and the parameter explanations are concise yet informative. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify what 'detailed information' includes (e.g., mesh data, transforms, materials). It also fails to mention any prerequisites or object types. For a tool with sibling get_scene_info, this gap hinders the agent from selecting it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema, which has no parameter descriptions (0% coverage). It explains object_name as 'the name of the object' and user_prompt as 'for telemetry,' providing necessary context. However, it could add examples or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get detailed information about a specific object in the Blender scene,' which clearly identifies the verb (Get), resource (detailed information about a specific object), and context (Blender scene). This distinguishes it from sibling tools like get_scene_info, which operates on the whole scene.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool vs. alternatives (e.g., get_scene_info). The description implies the tool is for individual objects but does not explicitly state usage context or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behaviors. It mentions returning a list with basic information but omits details on rate limits, authentication, or side effects. The user_prompt parameter is described as telemetry but not elaborated.
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?
Description is brief and structured with a main action followed by parameter explanations. No fluff, but could be more concise by merging parameter details with schema if schema were richer.
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 no output schema or annotations, the description is adequate but lacks detail on return format or pagination. For a simple search tool with optional params, it covers basics but leaves ambiguity about 'basic information.'
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 compensates by listing all three parameters and explaining asset_type options (hdris, textures, models, all), categories as optional comma-separated, and user_prompt as telemetry. Adds meaning beyond schema defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for assets on Polyhaven with optional filtering,' specifying the action and resource. It differentiates from sibling tools like download_polyhaven_asset and search_sketchfab_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_sketchfab_models. Does not mention context or exclusions, leaving the agent without clear decision criteria.
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. It only states the tool executes code but does not disclose potential risks (e.g., destructive changes), prerequisites, or side effects. This is insufficient for an arbitrary code execution 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 extremely concise: two lines of prose plus parameter list. It is front-loaded with the main purpose, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity and risk of arbitrary code execution, the description is severely lacking. It does not mention prerequisites (e.g., Blender running), error handling, return values, or safety considerations. The completeness is inadequate even with the parameter descriptions.
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 briefly explains each parameter: 'code: The Python code to execute' and 'user_prompt: The original user prompt... for telemetry'. This adds meaning beyond the schema's type/default, though it is minimal.
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 'Execute arbitrary Python code in Blender', specifying both the action (execute) and the resource (Python code in Blender). This distinguishes it from sibling tools which focus on assets and queries.
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 advises to 'do it step-by-step by breaking it into smaller chunks', providing a usage hint. However, it lacks explicit when-to-use vs. alternatives, and does not mention when not to use this tool.
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 fully disclose behavior. It mentions built-in materials, normalized size, and a success/failure return message. Missing critical context: the tool likely starts an async generation job (siblings like poll_rodin_job_status and get_hyper3d_status imply async), no mention of job polling status, blocking behavior, or side effects on the Blender scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with main purpose stated first, followed by bullet-like details. It contains no filler. Could benefit from structured formatting (e.g., explicit parameter descriptions separately) for easier parsing, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (generative model, import into Blender, multiple sibling tools), the description lacks essential context: async nature, how to poll/retrieve results, status checking, failure handling details, import behavior (e.g., replaces existing objects?), and any prerequisites (Blender open?). No output schema, so return format is vague. Incomplete for a generative 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 coverage is 0%, so description must explain parameters. It explains text_prompt (short English description) and bbox_condition (list of 3 floats for L/W/H ratio). However, user_prompt is completely omitted. bbox_condition explanation is helpful but could be more precise (e.g., 'array of three numbers' instead of 'list of floats of length 3').
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 'generate 3D asset using Hyper3D by giving description' and 'import the asset into Blender.' It uses specific verb-resource and distinguishes from sibling tools like generate_hyper3d_model_via_images (different input modality) and download/import tools (different origin).
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 advises providing a short description in English and notes that re-scaling may be useful due to normalized size. However, it does not specify when to prefer this tool over alternatives (e.g., generate_hunyuan3d_model or generate_hyper3d_model_via_images) and lacks exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Returns a message indicating success or failure', but does not disclose side effects (e.g., whether existing textures are replaced), error behaviors, or permission requirements. 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 three short sentences. It front-loads the purpose and uses a clear list format for parameters. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers the core action and prerequisite. However, it lacks details on error handling, success/failure conditions, and what happens to the object's material. Given the tool's limited complexity, it is minimally adequate but not thorough.
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 adds meaning for the two required parameters (object_name and texture_id) beyond their names in the schema. However, the optional user_prompt parameter is not described, and schema description coverage is 0%. The description partially compensates but misses covering all 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 verb 'Apply' and the resource 'previously downloaded Polyhaven texture to an object', which distinguishes it from sibling tools like download_polyhaven_asset and 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the prerequisite that the texture must be downloaded first ('must be downloaded first'), but it does not explicitly state when to use this tool versus alternatives or when not to use it. It provides some guidance but lacks explicit exclusion or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the tool is a read-only check and returns a message, but lacks details on return format, prerequisites, or side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with the primary action. Efficient and clear.
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 (status check with no output schema), the description is almost complete but leaves the unexplained parameter and return format ambiguous. Adequate minimal coverage.
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?
Schema coverage is 0% with one parameter 'user_prompt' having default empty string. The description does not explain its purpose or relationship to the check, leaving the agent uncertain about its necessity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Check' and resource 'Hyper3D Rodin integration', clearly distinguishing from sibling tools like generate_hyper3d_model_* and poll_rodin_job_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies checking integration status before using Hyper3D features, but does not explicitly state when to use or provide alternatives. No exclusions or context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that models have built-in materials and normalized size, and that re-scaling is useful. It says the tool returns a success/failure message. Since no annotations are provided, the description carries full burden but lacks details on error handling, authentication needs, or potential destructive actions.
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 fairly concise and structured: it starts with the main purpose, then lists parameters in a clear format. It avoids irrelevant detail. The omission of user_prompt is a minor structural flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, moderate complexity, and no output schema, the description provides a decent overview of the generation process and parameter usage. However, the missing parameter documentation and lack of detail on failure modes or output format make it incomplete.
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?
With 0% schema coverage, the description must fully document parameters. It describes input_image_paths, input_image_urls, and bbox_condition with specific format expectations (absolute paths, list wrapping, int array of length 3). However, it completely omits the user_prompt parameter, leaving it undocumented despite being present in 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 generates a 3D asset using Hyper3D from images and imports it into Blender. It distinguishes itself from siblings like generate_hyper3d_model_via_text, which uses text prompts, and other tools for downloading or 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 explains that only one of input_image_paths or input_image_urls should be provided depending on the Hyper3D Rodin mode, and notes bbox_condition as optional. However, it does not explicitly compare to alternatives like generate_hyper3d_model_via_text or state when to choose this over text-based generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation but does not explicitly confirm no side effects. With no annotations, the description carries the burden; mentioning that user_prompt is for telemetry adds a behavioral note, but it's not comprehensive.
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, using two sentences for purpose and one line per parameter. No wasted words, though the parameter list partly duplicates the schema.
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 a clear purpose, the description lacks any information about the return structure or output format. With no output schema and a task that returns data, the agent cannot predict what 'detailed information' entails.
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 crucial meaning to the user_prompt parameter beyond the schema (which has no property description). It explains the parameter is required for telemetry, clarifying its non-functional 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 explicitly states "Get detailed information about the current Blender scene," using a specific verb and resource. It clearly distinguishes from siblings like get_object_info, which targets 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 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 such as get_object_info or execute_blender_code. The context gives no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It states the tool returns a thumbnail as an Image, which is transparent about output. However, it does not disclose any error conditions, rate limits, or required permissions. For a simple read operation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences and a param list. The first sentence states the purpose, the second gives usage guidance. It efficiently conveys the essential information without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (2 params, no output schema, no annotations), the description covers the tool's purpose, parameter, and return type. However, the optional 'user_prompt' parameter is undocumented, which is a minor gap.
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?
Schema description coverage is 0%, so description must add meaning. It explains the required 'uid' parameter as 'unique identifier from search_sketchfab_models', which adds context. However, the optional 'user_prompt' parameter is not explained in the description, leaving its purpose unclear.
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 'Get a preview thumbnail' and the resource 'Sketchfab model by its UID'. It distinguishes from sibling tools like download_sketchfab_model, which downloads the full 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 explicitly says 'Use this to visually confirm a model before downloading', providing clear context for when to use it. It implies not to use it for downloading, but lacks explicit exclusions or 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 full burden. It states 'capture a screenshot' but does not disclose whether the tool is read-only, if it modifies the scene, or any side effects. Although a screenshot is typically non-destructive, the description lacks explicit assurance or details on behavior like output format or viewport requirements.
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: one line for purpose, then a bullet list for parameters. Every sentence adds value, and the most important information (what the tool does) is front-loaded. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the essential aspects: purpose, parameters, and return type ('Image'). It lacks output schema and does not specify image format or resolution details, but for a straightforward screenshot capture, this is largely sufficient. An explicit mention of read-only nature 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?
Schema description coverage is 0%, so the description must compensate. It explains that max_size is 'Maximum size in pixels for the largest dimension' and user_prompt is for telemetry. This adds meaningful context beyond the schema's type/default, though it could specify units (pixels is clear) or that max_size controls the largest side.
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 verb ('capture') and resource ('screenshot of the current Blender 3D viewport'). It is distinct from sibling tools, which focus on asset downloads, code execution, or scene information, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when-to-use or alternatives are given, the context is clear: it captures a viewport screenshot. Since no sibling tools offer the same functionality, no exclusions are needed. The description implies usage for obtaining a visual representation of the 3D scene.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses scaling and return of import details, but omits potential side effects (e.g., scene impact) and error conditions. No annotations to supplement.
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?
Concise with clear structure: main purpose, scaling, then parameter details with examples. No 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?
Adequately covers main operation but lacks details on error handling and omission of user_prompt. Output is described but no 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?
Describes uid and target_size with examples, covering the two required params. However, user_prompt parameter is not mentioned in description despite being in 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?
Clearly states download and import of Sketchfab model by UID with scaling. Distinguishes from sibling search and preview tools.
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 prerequisites (downloadable, access rights) and examples for target_size, but doesn't explicitly mention alternatives or when not to use.
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 mentions the return value indicates success, but does not disclose potential side effects (e.g., scene modification, permissions). Adequate but lacks depth.
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 two distinct sections: purpose and parameter details. Every sentence adds value, no 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 3-parameter tool with no output schema, the description explains all parameters and return, but missing details on error behavior or consequences of invalid inputs.
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%, but the description compensates fully: explains `name` as scene object name, `task_uuid` and `request_id` in context of Rodin mode, and warns about exclusive use.
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 imports a generated asset from Hyper3D Rodin, distinguishing it from the sibling `import_generated_asset_hunyuan`. The verb 'import' and specific resource 'asset generated by Hyper3D Rodin' are explicit.
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 guidance on parameter selection based on Rodin mode, but does not explicitly exclude usage for Hunyuan3D or mention when not to use this 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?
No annotations are provided, so the description carries full burden. It discloses that the tool returns status ('DONE', 'RUN'), that 'DONE' includes 'ResultFile3Ds' with the ZIP path, and that it should be polled. It could mention error states more precisely but is generally 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 a clear opening sentence, parameter list, and return details. It is slightly verbose but front-loads the purpose and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description is complete: it explains the return format (status, ResultFile3Ds), the polling requirement, and references the generation step. No gaps remain.
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 one parameter 'job_id' with 0% description coverage. The description adds value by stating 'the job_id given in the generate model step,' providing context about its origin beyond the schema's basic type and title.
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 'Check if the Hunyuan3D generation task is completed,' clearly specifying the verb ('check') and resource ('Hunyuan3D generation task'). It distinguishes from sibling tools like 'get_hunyuan3d_status' and 'poll_rodin_job_status' by focusing on polling 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?
The description explicitly says 'This is a polling API, so only proceed if the status are finally determined,' providing clear guidance on when to use (poll until done) and implying when not to use. It does not directly mention alternatives but the polling context is sufficient.
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 fully discloses that it is a polling API, explains status meanings and final states, and indicates return formats. It could add info on rate limits or cancellation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for each mode, but some information is repeated (e.g., polling nature mentioned twice). It could be slightly more concise while remaining clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of two modes and two parameters, the description covers all necessary information: parameter usage, status meanings, polling stop conditions, and return values. No output schema exists, but the description compensates.
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 0% schema coverage, the description thoroughly explains each parameter's purpose and which mode it applies to (subscription_key for MAIN_SITE, request_id for FAL_AI), adding significant value.
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 generation is completed, with distinct handling for two modes. The verb 'poll' and resource 'job status' are specific and distinguish it from sibling tools like poll_hunyuan_job_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to stop polling (status determined) and what constitutes success/failure for each mode. However, it does not explicitly mention when not to use this tool or alternative tools.
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_test MCP server](https://glama.ai/mcp/servers/Apteryx-T/blender_mcp_test/badges/card.svg)](https://glama.ai/mcp/servers/Apteryx-T/blender_mcp_test)

Score Badge

Copy to your README.md:

[![blender_mcp_test MCP server](https://glama.ai/mcp/servers/Apteryx-T/blender_mcp_test/badges/score.svg)](https://glama.ai/mcp/servers/Apteryx-T/blender_mcp_test)

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/Apteryx-T/blender_mcp_test'

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