BlenderMCP

Server Quality Checklist

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

Latest release: v1.9.2
Disambiguation4/5
Each tool targets a specific operation (e.g., search, download, generate, poll, import) and provider (Polyhaven, Sketchfab, Hyper3D, Hunyuan3D), so ambiguity is low. The multiple generate/poll/import tools are distinguishable by their provider-specific names, though close reading is needed to avoid selecting the wrong integration.
Naming Consistency3/5
Most tools follow a verb_noun pattern with provider prefixes, but there are inconsistencies: 'import_generated_asset' lacks a provider suffix while 'import_generated_asset_hunyuan' includes it, and 'poll_rodin_job_status' uses 'rodin' instead of 'hyper3d'. These deviations prevent a perfect consistency score.
Tool Count3/5
With 22 tools, the server is on the heavy side, falling into the 16-25 range that feels crowded. However, the count is justified by the multiple external integrations (Polyhaven, Sketchfab, Hyper3D, Hunyuan3D), each requiring several distinct operations.
Completeness3/5
The tool set covers asset discovery, download, generation, and import for multiple providers, but core Blender manipulation is limited to info and screenshot tools plus an arbitrary code execution escape hatch. This makes the surface functional but incomplete for direct object manipulation workflows.
Average 3.8/5 across 22 of 22 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
The description implies a read operation but does not disclose what 'detailed information' includes, error behavior for nonexistent objects, or any side effects. With no annotations, the description carries the full transparency burden and falls short.
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 well-structured, opening with a clear purpose sentence followed by a parameter list. It avoids unnecessary detail and is easy to scan.
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?
With no annotations and no output schema, the description alone must explain return values, error conditions, and prerequisites. It only states that it gets information, leaving ambiguity about what is returned and how to handle invalid inputs. This is inadequate for an agent to fully rely on it.
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 both parameters, adding meaning beyond the bare schema titles. However, the explanations are shallow—object_name is self-evident and user_prompt is only labeled as telemetry. With 0% schema coverage, it partially compensates but not deeply.
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 'Get detailed information about a specific object in the Blender scene,' which conveys the verb+resource pattern. It is distinct from siblings like get_scene_info, though it does not explicitly call out the difference.
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. There is no mention of using it for object-specific queries or referencing get_scene_info for scene-level info.
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 behavioral disclosure. It states it downloads and imports but doesn't explain side effects like where the asset is saved, whether it modifies the Blender scene permanently, error conditions, or whether network access is required. Returns 'a message' but without 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 and not overly long. The parameter list is somewhat redundant with the schema, but since the schema has no descriptions, it serves a purpose. Each sentence contributes to understanding the tool.
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 description omits important context: no output schema, no error handling, no relationship to other tools, no mention of pipeline prerequisites. It leaves questions about what 'import' entails and what the success/failure message looks like, making it incomplete for a 5-parameter 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?
Despite 0% schema description coverage, the description lists all parameters and provides useful examples (e.g., asset_type 'hdris, textures, models'; file_format examples per type). However, it lacks deeper semantics like how to format asset_id or what happens with defaults, so it only partially compensates for the schema's missing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Download and import a Polyhaven asset into Blender.' This is specific and distinguishes it from siblings like search_polyhaven_assets or download_sketchfab_model, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 prerequisites like having an asset_id from a search, nor does it reference sibling tools. The intended usage context must be inferred from the name.
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 disclose behavioral traits, but it only mentions returning a formatted list. It does not address external API calls, rate limits, authentication, pagination, or how results are sorted. This leaves the agent uninformed about potential side effects or constraints.
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 purpose sentence, a short parameter list, and a return line. It avoids redundancy and front-loads the essential purpose, making it easy to parse.
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 description is incomplete for a tool with five parameters and no output schema. It omits user_prompt, does not specify the structure of the formatted list, and lacks details like allowed category values or result fields. An agent cannot fully anticipate the tool's behavior or output.
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 four of five parameters (query, categories, count, downloadable) with clear semantics and defaults, which is beneficial since the schema has no field descriptions. However, it omits the 'user_prompt' parameter entirely, leaving a significant gap in 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's function: 'Search for models on Sketchfab with optional filtering.' The verb 'search' combined with the explicit platform 'Sketchfab' distinguishes it from sibling tools like search_polyhaven_assets and from Sketchfab-specific actions like download or preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention conditions for preferring this over search_polyhaven_assets or other search/download tools. The description implies usage for finding Sketchfab models but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose that the tool returns a message indicating feature availability, which is useful. However, it does not mention potential side effects (if any), network interactions, or the exact structure of the message. For a status check, this is minimal but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two short sentences that front-load the purpose ('Check if...') and immediately follow with the return behavior. Every word contributes value, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's core purpose and return type, which is adequate for a simple status check. However, it omits any explanation of the optional 'user_prompt' parameter, which is part of the invocation context. Given the tool's simplicity, the description is mostly complete but has a clear gap around parameter meaning.
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 defines a single optional parameter 'user_prompt' with a default of '', but the description does not explain what this parameter is for or how it affects the status check. With schema description coverage at 0%, the agent has no semantic guidance for supplying this parameter. The description completely ignores the parameter, leaving a significant ambiguity.
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 primary function: checking if Hyper3D Rodin integration is enabled in Blender. The verb 'check' and resource 'Hyper3D Rodin integration' are specific, and the mention of the integration name distinguishes it from sibling status tools like get_polyhaven_status and get_sketchfab_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 the tool is for verifying Hyper3D Rodin availability, which suggests using it before generating models. However, it does not explicitly state when to use it versus other status tools or when not to use it, and no alternatives are mentioned. The sibling tool names are present in context but not referenced in the description.
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 user_prompt is for telemetry and states the return type, but it does not explicitly confirm the operation is read-only, whether it works in headless mode, or any side effects. The telemetry note adds some value, but overall transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, stating the purpose first, then listing parameters and return value. It wastes no words, though it duplicates schema info and contains a default-value inconsistency that slightly detracts from its structure.
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 purpose, parameters, and return type. However, it lacks usage context—such as when to choose this over alternatives—and doesn't address potential caveats like viewport availability or rendering modes. Given no annotations or output schema, it is minimally adequate.
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 both parameters, providing meaning for max_size and user_prompt, which compensates for the 0% schema description coverage. However, it lists the default for max_size as 800 while the schema states 1000, creating confusion and reducing reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Capture') and resource ('current Blender 3D viewport'), distinguishing it from sibling tools like get_scene_info and get_object_info which retrieve data rather than images.
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 does it mention prerequisites or compare with other capture tools. It simply states the action, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must handle behavioral disclosure. It mentions that a success/failure message is returned and that the texture must be downloaded first, but it does not disclose side effects like overwriting existing materials or error behavior if the texture is not found. This leaves important behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with a clear purpose sentence followed by a compact parameter list. Every sentence adds value, and there is no filler or 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?
This is a mutation tool with no annotations or output schema, and the description does not fully compensate. It lacks details on error handling, effect on existing materials, and the meaning of the success message. The missing user_prompt documentation further reduces 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?
The description adds meaning for object_name and texture_id, clarifying that texture_id must reference a previously downloaded asset. However, it omits the optional user_prompt parameter entirely, so not all parameters are explained. Given the 0% schema description coverage, the description partially compensates but has a 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 applies a previously downloaded Polyhaven texture to an object. The verb 'apply' and resource 'Polyhaven texture' are specific, and the tool is clearly distinguished from siblings like download_polyhaven_asset 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 conveys a prerequisite (texture must be downloaded first) but does not explicitly state when to use this tool over alternatives or mention any exclusions. The usage context is implied but not fully elaborated.
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 transparency burden. It discloses the return type ('a message') and the nature of the check (availability), but it does not describe the user_prompt parameter or any potential side effects. Since this is a read-only status operation, the lack of explicit safety disclosure is partially mitigated by the verb 'Check,' but the unexplained parameter creates a transparency 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 two sentences long, front-loaded with the primary purpose, and includes the return behavior. Every word earns its place—no redundancy, no fluff. It is 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?
For a simple status-check tool, the description covers the basic behavior and return value. However, the presence of an unexplained parameter and the absence of an output schema or annotations mean the description leaves gaps. An agent would not know what to pass as user_prompt or what the exact message format is, so the context is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the lone parameter 'user_prompt' has no schema description and is not mentioned in the tool description. The description provides zero value in clarifying what this parameter does or how it relates to checking status. This is a critical miss for a parameter with no other 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 action ('Check if Sketchfab integration is enabled in Blender') with a specific verb and resource. It distinguishes this tool from sibling status checkers (e.g., get_polyhaven_status, get_hyper3d_status) by naming the Sketchfab integration explicitly. The return value is also specified, 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?
The description implies usage: when you need to determine if Sketchfab features are available before using them. It provides clear context for when to use this tool, though it does not explicitly mention alternatives or when not to use it. Given the simple nature of a status check and the distinct sibling names, the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the output (built-in materials), a key property (normalized size), and the return type (success/failure message). However, it does not mention potential side effects like scene modification, generation time, or error handling for invalid prompts. The behavioral disclosures are helpful 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?
The description is brief and well-organized: a purpose sentence, two short behavioral notes, and a parameter list. Each sentence contributes useful information without redundancy. The parameter bullet points are easy to scan, and the entire description is front-loaded with the core action.
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 purpose, key output properties, parameter semantics for two of three params, and the return message. It lacks explanation for the user_prompt parameter and does not mention if the generation process is asynchronous (especially given sibling tools like poll_rodin_job_status). For a generation tool, additional context about workflow expectations (e.g., importing modifies the Blender scene) could be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description is the sole source of parameter meaning. It explains text_prompt (short English description) and bbox_condition (optional list of floats for length/width/height ratio). However, user_prompt from the schema is not described, leaving a parameter unaccounted for. The descriptions provided are clear and add value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate 3D asset using Hyper3D by giving description of the desired asset, and import the asset into Blender.' This identifies the specific service (Hyper3D), the input modality (text description), and the output action (import into Blender). It distinguishes from sibling tools like generate_hyper3d_model_via_images, which uses images instead of text.
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 a text description is available, but it does not explicitly reference alternatives or exclusionary conditions. The mention of 'text' in the description gives some guidance, yet there is no comparison to generate_hunyuan3d_model or other 3D generation tools. No 'when not to use' scenarios are provided.
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 states the return is a message indicating availability, but doesn't explicitly confirm a read-only operation or disclose other behavioral traits. It's adequate for a simple status check 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 two concise sentences with the purpose front-loaded. There is no redundancy or irrelevant information.
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 is sufficient for a simple status tool, but it omits the 'user_prompt' parameter semantics and gives only a vague description of the return value. Given no output schema and no annotations, this is a noticeable but not critical 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?
The input schema includes a 'user_prompt' parameter with 0% description coverage. The description does not explain what this parameter does or why it exists, leaving the agent without guidance on whether or how to populate it.
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. This specific verb+resource combination distinguishes it from sibling status tools for other integrations and from Hunyuan generation/polling 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?
It implies usage when needing to verify Hunyuan3D availability before using related features. However, it doesn't explicitly mention alternatives or when not to use it, though the integration-specific naming makes the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the operation type (get) but gives no details about side effects, network dependencies, potential errors, or return format. For a simple read operation, this is a noticeable gap, though not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first delivers the core purpose, the second lists parameters with terse explanations. Every word earns its place, and the structure is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 params, no output schema, and no annotations, the description covers the purpose and parameter semantics sufficiently. It could mention the return value or any practical constraints, but the tool's low complexity keeps the need modest. The missing usage guidance is the main deficit.
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 coverage is 0%, but the description compensates by detailing both parameters. It explicitly lists the accepted values for asset_type (hdris, textures, models, all) and explains that user_prompt is for telemetry, adding meaning beyond the bare 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?
The description clearly states the verb 'Get', the resource 'categories', and the scope 'for a specific asset type on Polyhaven'. This distinguishes it from sibling tools like search_polyhaven_assets or download_polyhaven_asset, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance about when to use this tool versus alternatives is provided. While the purpose is clear and implies usage, the description does not mention when not to use it or point to other tools for other needs. This is minimal viable but lacks the explicit differentiation seen in better descriptions.
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 the full burden. It discloses that the tool 'returns a message indicating whether PolyHaven features are available', which gives useful behavioral context about the return value. It does not mention side effects, but a status check is implicitly non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no fluff. Every word contributes to understanding the tool's function and return behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status-check tool, the description covers the essentials: what it checks and what it returns. However, it omits any details about the user_prompt parameter and does not describe possible error conditions or output format. Given the tool's low complexity, this 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?
The schema has one parameter (user_prompt) with 0% description coverage, and the description does not mention it at all. Since the parameter is optional and undocumented, the agent has no guidance on what to pass or why. The description fails to compensate for the schema's lack of parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Check if PolyHaven integration is enabled in Blender') with a specific verb and resource. It distinguishes this tool from sibling status checkers (e.g., get_hyper3d_status, get_sketchfab_status) by explicitly naming PolyHaven.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: the tool checks PolyHaven availability. However, there is no explicit guidance on when to use this versus alternative status tools, nor any exclusions. The description simply explains what it does without offering decision 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 present, so the description carries the full burden. It discloses that the return includes blender_version and blender_version_string, which is useful behavioral detail. However, it does not enumerate the full scope of 'detailed information' or mention potential errors or side effects, leaving some opacity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear one-line purpose, a specific detail about version fields, and a parameter list. Every sentence earns its place 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?
Given the tool's low complexity (single optional parameter, no output schema), the description mentions the key version fields and purpose. However, 'detailed information' remains vague, and without an output schema the agent lacks a complete picture of available scene data, which could matter for downstream decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the tool description explains that user_prompt is an optional original user prompt used for telemetry. This adds semantic meaning beyond the schema's type/default, effectively compensating 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 uses a specific verb ('Get') and resource ('detailed information about the current Blender scene'), which clearly distinguishes it from sibling tools like get_object_info and get_viewport_screenshot. It further specifies that it includes blender_version and blender_version_string, adding concrete scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or alternative guidance. The mention of 'for API branching' implies a usage context, but it does not state when to prefer this over get_object_info or other tools. This is implied usage only, not explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the polling nature, how to interpret statuses (DONE vs RUN), and that a successful response includes a ResultFile3Ds field with the generated ZIP path. This goes beyond a generic status check, though it repeats the ResultFile3Ds detail and doesn't enumerate possible failure states.
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 moderately concise but contains redundancy: the ResultFile3Ds return is described twice in successive sentences. The formatting with a 'Parameters' block is awkward, but the overall length is acceptable.
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 no output schema, the description covers the statuses and result field, and provides a clear poll-until-done instruction. It could be improved by listing explicit failure states, but it is otherwise complete for an agent to know when to stop polling and what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines job_id as a string with a default of null, so the description's clarification that it is 'given in the generate model step' adds essential provenance context. It doesn't explicitly state that job_id is required, but it is strongly implied.
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 a Hunyuan3D generation task is completed, naming the specific action and resource. However, it does not explicitly differentiate from sibling tools like get_hunyuan3d_status, leaving some ambiguity about when to use this specific polling endpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives usage context by referencing the job_id from the generate step and explains it is a polling API with a stop condition ('only proceed if the status are finally determined'). It does not name alternative tools or exclusion criteria, but the polling behavior and poll-until-final guidance are 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 full burden. It discloses the asynchronous behavior via 'job_id' and status change to 'DONE', mentions built-in materials, and describes error handling. It does not mention prerequisites like Blender running or potential side effects, but the core workflow is well conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, a parameters list, and a returns section. It is concise, with every sentence adding value. The front-loaded purpose makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main flow: input, generation, import, and return values. It does not explain how to check the job status (though a sibling poll tool exists) or discuss timeouts, but for a tool with no output schema and moderate complexity, it is quite 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 and input_image_url, including that image accepts None for text-only. However, it omits the user_prompt parameter entirely, leaving it unexplained. This is a partial compensation with a clear 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 purpose: 'Generate 3D asset using Hunyuan3D by providing either text description, image reference, or both for the desired asset, and import the asset into Blender.' This specifies the verb, resource, and action. It also distinguishes from siblings like generate_hyper3d_model_via_text by naming the Hunyuan3D model and the import step.
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 the inputs ('providing either text description, image reference, or both') and notes that the asset is imported into Blender, but it does not explicitly compare this tool to alternative generation tools (e.g., generate_hyper3d_model_via_text) or state when to prefer one over the other. Usage context is implied but no exclusion or alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses useful behavior: built-in materials, normalized size, and a return message. It does not mention asynchronous behavior or the need to poll job status, which is a minor gap given sibling tools, but the core side effects are covered.
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 brief intro and a parameter breakdown. All sentences contribute useful information, though the parameter section is somewhat dense and could be tightened.
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 purpose, input modes, output, and post-generation properties, but misses user_prompt, lacks clarity on whether it submits a job or completes generation, and does not explain the relationship to poll_rodin_job_status. These gaps prevent it from being 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?
The description thoroughly explains three of four parameters, including absolute paths, list wrapping, and bbox condition constraints. However, user_prompt is completely omitted, and schema coverage is 0%, leaving a gap for that parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a 3D asset from images via Hyper3D and importing it into Blender. It uses a specific verb and resource, and distinguishes from sibling tools like generate_hyper3d_model_via_text and import_generated_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 use input_image_paths versus input_image_urls based on the Hyper3D Rodin mode, and explicitly states only one should be given. It does not explicitly mention when to use this tool over generate_hyper3d_model_via_text, but that is implied by the input type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states that the tool 'Returns the model's thumbnail as an Image for visual confirmation,' which discloses the key output behavior. The term 'preview' and the phrase 'before downloading' imply it does not download the full model. However, it does not explicitly mention network usage, caching, or any side effects, but for a simple read-only preview tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose followed by usage, parameters, and return value. Every sentence earns its place, with no fluff or repetition. It is appropriately sized for the tool's simplicity.
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 low-complexity tool, the description covers the main purpose, input, and output. However, it fails to document the optional user_prompt parameter, and it does not mention any potential errors or network dependencies. The absence of an output schema increases the need for description completeness, and the missing parameter documentation is a clear 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 coverage is 0%, so the description must compensate. It explains uid well, including its origin from search_sketchfab_models, but completely omits the optional user_prompt parameter. This leaves a documented schema parameter unexplained, so the description adds some value for one parameter but fails on the other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Get a preview thumbnail of a Sketchfab model by its UID.' This clearly states what the tool does and differentiates it from siblings like download_sketchfab_model and search_sketchfab_models, as it focuses on visual preview rather than downloading or searching.
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 usage context. It also mentions the UID is obtained from search_sketchfab_models, giving a hint about the integration flow. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls just short of a 5.
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 present, so the description must convey behavioral traits. It explains the parameters and states the return type ('a list of matching assets with basic information'), but omits details like pagination, authentication, rate limits, or how filtering criteria interact. It does disclose that user_prompt is for telemetry, which adds slight transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear one-sentence purpose followed by a bulleted parameter list and a one-line return statement. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with no output schema and no annotations, the description is fairly complete. It covers the parameters, return type, and telemetry purpose. It could be more specific about output fields or filtering behavior, but overall it provides enough context for an agent to use the tool 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?
Schema description coverage is 0%, so the description compensates by listing and explaining all three parameters: asset_type with allowed values, categories as comma-separated, and user_prompt for telemetry. This goes beyond the schema's bare defaults and provides useful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for assets on Polyhaven with optional filtering.' It uses a specific verb ('search') and resource ('Polyhaven assets'), and the name distinguishes it from sibling tools like 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching Polyhaven assets but does not explicitly provide when-to-use vs. alternatives, nor does it mention exclusion criteria. No guidance is given for when to use search_polyhaven_assets over search_sketchfab_models or other asset-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral info. It explains that the asset will be imported into the scene with the given object name and returns success/failure. However, it does not disclose potential side effects like overwriting existing objects or any required permissions, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a two-item parameter list, and a return statement. Every line adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the purpose, parameters, and return value adequately. It could mention error handling or how to obtain the zip_file_url more explicitly, but for a simple import tool it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero coverage (no descriptions in the schema), so the description fully compensates by explaining both parameters: 'name' is the object name in the scene, and 'zip_file_url' is the URL from the generation step. This provides essential semantic context beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports an asset generated by Hunyuan3D, using a specific verb and resource. It mentions the timing (after generation task) and the source (Hunyuan3D), which helps distinguish it from the generic sibling 'import_generated_asset', though it does not explicitly contrast them.
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 usage context: it should be used after the generation task is completed, and the zip_file_url should be taken from the generation step. This implicitly differentiates it from other import tools, though it doesn't mention specific alternatives or say 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses scaling behavior (largest dimension equals target_size), return message details, and access rights requirement. This is strong, though it omits potential failure modes or side effects beyond the access condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear one-sentence purpose, a scaling note, and a parameter list with examples. Every sentence contributes value, and no fluff is present.
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 essential aspects: what the tool does, how to use it (params), what to expect (scaled model, return message), and requirements (access rights). It would benefit from mentioning common failure modes or clarifying the import side effects, but it is largely complete for an agent to invoke it correctly.
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 uid and target_size with detailed examples and semantics, far exceeding the empty schema. However, it completely ignores user_prompt, which is a third parameter present in the schema, so not all parameters are covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Download and import') and resource ('Sketchfab model') and identifies the unique key ('by its UID'), clearly distinguishing it from sibling tools like search_sketchfab_models or get_sketchfab_model_preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys the context for use: when you have a UID and want to import the model. It does not explicitly mention when not to use it or alternatives, but the purpose is unambiguous enough that an agent can infer when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states that the tool executes arbitrary Blender Python code and explains the file_path behavior. However, it does not disclose whether scene changes persist, what the return value might be (e.g., stdout, errors), or any safety caveats, leaving notable gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, two sentences of usage guidance, and a three-bullet parameter list. Every sentence adds value and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex code-execution tool with no output schema, the description covers parameters and usage well. However, it does not mention what the tool returns after execution, whether errors are surfaced, or if changes to the Blender scene persist. This is a meaningful gap given the tool's power and the absence of structured output information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only raw string fields with no descriptions, and coverage is 0%. The description fully compensates with a clean parameter list that explains code, file_path, and user_prompt, including the optional relationship and precedence. This is far beyond what the schema supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Execute arbitrary Python code in Blender' with a specific verb and resource. It is unmistakably distinct from sibling tools, which are all getters or asset-management operations, and no other tool executes arbitrary code.
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 gives practical guidance on passing code vs. file_path, including the trade-off (server reads file, cheaper for large scripts) and precedence when both are provided. It does not explicitly list alternatives or exclusions, but the sibling tools are clearly different in purpose, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return value ('Return if the asset has been imported successfully') and the mode-specific identifier requirements, but it doesn't cover error handling, idempotency, or side effects on the scene. This is moderate transparency, 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 concise and well-structured: a clear opening sentence, a bulleted parameter list, a usage note, and a return statement. Every sentence serves a purpose 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?
Given the tool's dependency on a prior generation step and mode-specific identifiers, the description covers the prerequisites, the identifier selection logic, and the return behavior. It doesn't mention potential failure scenarios, but for a straightforward import tool, the description is sufficiently complete.
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?
Since schema coverage is 0%, the description compensates fully by explaining each parameter: name is the object name in scene, task_uuid is for MAIN_SITE, request_id is for FAL_AI, and it specifies that only one of the two should be provided. This adds significant 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's action: 'Import the asset generated by Hyper3D Rodin after the generation task is completed.' It identifies the specific resource (Hyper3D Rodin assets) and distinguishes it from the sibling tool import_generated_asset_hunyuan by explicitly naming Hyper3D Rodin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'after the generation task is completed' and instructs to give exactly one of task_uuid or request_id based on the mode. It does not explicitly mention the alternative Hunyuan import tool, but the Hyper3D Rodin label makes the appropriate context 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 provided, the description discloses key behavioral traits: it returns a list of statuses (MAIN_SITE) or a single status (FAL_AI), defines terminal states ('Done', 'Canceled', 'COMPLETED', or failed states), and warns about polling semantics. This goes beyond a simple 'check status' and effectively communicates the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear sections by mode, with every sentence providing useful information. It is appropriately detailed for the complexity of two modes and avoids redundant or filler content. The structure makes it easy to scan and parse.
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?
The description fully covers the tool's purpose, parameter usage, status interpretation, and polling behavior for both modes. Given the lack of output schema, it also explains return values and success/failure criteria. This is complete for the tool's complexity and does not leave obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to the parameters. It does exactly that by explaining that 'subscription_key' comes from the generate model step for MAIN_SITE mode and 'request_id' for FAL_AI mode. This clarifies the purpose of each parameter beyond the bare schema definitions.
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. It distinguishes between two modes (MAIN_SITE and FAL_AI) and specifies the resource and verb, differentiating it from sibling polling tools like poll_hunyuan_job_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on how to interpret statuses and when to proceed, stating 'This is a polling API, so only proceed if the status are finally determined.' It explains the success/failure conditions for each mode, though it does not explicitly name alternative tools. The context is clear enough for an agent to know when 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/KorwinTeo/blender-mcp'

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