blender-mcp

by silwings1986

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v1.5.5
Disambiguation5/5
Each tool targets a distinct operation or external service (Polyhaven, Sketchfab, Hyper3D, Hunyuan3D) with no overlap. Scene info, viewport screenshot, code execution, and service-specific status/search/download/generate/poll/import tools are all clearly separated.
Naming Consistency4/5
Naming follows a generally consistent pattern with verbs like get_, search_, download_, generate_, poll_, import_. Minor inconsistencies exist (e.g., 'get_sketchfab_model_preview' vs 'download_sketchfab_model', and 'import_generated_asset_hunyuan' differs from 'import_generated_asset'), but within each subdomain the pattern is clear.
Tool Count4/5
22 tools is slightly above the ideal range but still appropriate given the integration of multiple external asset services (Polyhaven, Sketchfab, Hyper3D, Hunyuan3D) each requiring their own set of operations. The count is not excessive.
Completeness4/5
The tool surface covers the full workflow for importing assets from external services (status check, search, preview, download, apply/generate, poll, import). Basic Blender scene introspection is provided. Minor gaps like direct scene manipulation or deletion tools are absent but outside the server's apparent scope.
Average 3.7/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
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states 'get', implying read-only, but does not disclose what happens if the object doesn't exist, whether there are permissions needed, or what exactly 'detailed information' includes. This is insufficient for a safe read operation.
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 very short with one sentence for purpose and one for parameter. It is front-loaded but lacks detail. While concise, it sacrifices completeness for brevity.
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 (one param, no output schema), the description should at least hint at what information is returned and error cases. It does not. The minimal text leaves the agent guessing about the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a sentence for the parameter 'object_name' that repeats the schema title: 'The name of the object to get information about'. This adds minimal value beyond the schema, especially given 0% schema description coverage. The description does not clarify constraints or expected format.
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 gets 'detailed information about a specific object', using a specific verb and resource. It differentiates from the sibling 'get_scene_info' by focusing on objects. However, 'detailed information' is somewhat vague.
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 get_scene_info or other query tools. The description does not provide context for use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description gives vague behavioral hints ('silently remember it') without clarifying side effects, required permissions, or response format.
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?
Two sentences, but the second sentence adds unclear instruction ('Don't emphasize the key type...') which reduces clarity; could be more concise without this noise.
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?
Lacks return value details (only says 'returns a message'), no output schema, and the instruction about key type is confusing; incomplete for a status-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description does not need to add param details; the schema covers 100% of (non-existent) parameters.
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 Hyper3D Rodin integration is enabled, but does not differentiate from similar sibling status tools like get_polyhaven_status or 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 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; usage is only implied by the generic status-check purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states returns basic info but does not disclose pagination, rate limits, or how filters are combined (AND/OR). This is minimal disclosure for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose statement and bulleted parameter explanations. It is front-loaded and each sentence adds value, though it could be slightly tighter.
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 search tool with 2 parameters and no output schema, the description covers basic use. However, it omits context like ordering, pagination, or examples, which would improve 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?
Schema description coverage is 0%, so the description must compensate. It explains asset_type values (hdris, textures, models, all) and categories as comma-separated filter. This adds meaning but lacks details about parameter interaction or default behavior.
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 'Search for assets on Polyhaven' with optional filtering, specifying the verb (search), resource (assets on Polyhaven), and filtering capability. It distinguishes from sibling tools like search_sketchfab_models and 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?
No guidance is provided on when to use this tool versus alternatives like get_polyhaven_categories or search_sketchfab_models. The description lacks any when/to/when-not-to-use instructions.
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 bears full burden. It fails to disclose side effects on Blender state, error behavior, or return values. For a powerful tool executing arbitrary code, this transparency is insufficient.
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, front-loaded with the main action. It is concise but could be more structured. The step-by-step advice is useful but brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 1 parameter, no output schema, and no annotations, the description lacks details on success/failure, output format, and Blender environment changes. It is incomplete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description for parameter 'code' simply restates 'The Python code to execute', which adds no meaning beyond the schema. With 0% schema description coverage, the description should compensate but does not.
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 name 'execute_blender_code' and description 'Execute arbitrary Python code in Blender' clearly state the verb and resource. The tool is distinct from siblings like get_scene_info or generate_hyper3d_model_via_text, which perform different tasks.
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 break code into smaller chunks, providing a usage hint. However, it lacks explicit guidance on when to use this tool versus alternatives or when not to use it. The sibling list implies usage for code execution, but not explicit 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?
The description only says 'get a list', with no details on behavior like read-only nature, error handling, or return format. No annotations compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and a simple param list. No wasted words.
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 one parameter and no output schema, the description covers the purpose and parameter but lacks return format details. Adequate but not thorough.
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 parameter is described with examples ('hdris, textures, models, all'), adding value beyond the schema which only has type string. This helps the agent understand valid inputs.
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 given asset type on Polyhaven. While it distinguishes from siblings implicitly (siblings are for different tasks), it lacks explicit differentiation.
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. The description only states what it does, not when it should be used, e.g., before downloading an asset.
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 carries full burden. It only says 'Returns a formatted list' without disclosing behavioral traits like read-only nature, rate limits, authentication, or what 'formatted' means.
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 relatively concise, listing parameters inline without unnecessary detail. However, it could be more structured (e.g., separate paragraphs for purpose and parameters).
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 4-parameter search tool with no output schema, the description adequately covers parameters but minimally describes output ('formatted list'), lacking details on pagination, error handling, or result structure.
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?
With 0% schema description coverage, the description compensates by explaining each parameter's purpose (query, categories as comma-separated, count as max results with default 20, downloadable with default True), adding 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?
The description clearly states 'Search for models on Sketchfab with optional filtering', specifying the verb (search), resource (models on Sketchfab), and scope. It distinguishes from sibling tools like download_sketchfab_model and 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 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 vs alternatives, no when-not-to-use conditions, and no mention of prerequisites or context for usage.
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 carries full burden. It discloses the action (download and import) and return type (success/failure message), but omits critical behavioral details such as whether importing overwrites existing data, file path conventions, authorization needs, 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?
The description is concise with a one-line summary then structured parameter list. It is front-loaded with the core purpose. The return message description is minimal but adequate.
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 complexity (download and import with multiple formats), the description covers purpose, parameters, and return type but lacks behavioral context (e.g., side effects, prerequisites). Absence of output schema increases the need for such detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains each parameter's purpose and provides type-specific examples for asset_type and file_format. This adds meaningful guidance beyond the bare schema, though enumeration of valid values is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'download and import' and the resource 'Polyhaven asset into Blender'. It is distinct from sibling tools like search_polyhaven_assets or get_polyhaven_categories, 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?
The description implies the tool is for downloading assets but does not explicitly state when to use it versus alternatives (e.g., after searching with search_polyhaven_assets). No exclusions or when-not-to-use guidance 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 provided, so description carries full burden. Discloses return of a message but not its structure, nor any side effects. Includes a hidden instruction about key type, which is not transparency about tool 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?
Two sentences, first is concise and front-loaded. Second sentence is a meta-instruction that could be omitted or placed elsewhere, slightly reducing conciseness.
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?
No output schema, so description should detail return value. Only says 'message indicating availability' without specifying format or content. Adequate for simple check but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, schema coverage 100%. Baseline 4 applies as description adds no parameter info beyond 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 the tool checks if Hunyuan3D integration is enabled and returns an availability message. Verb 'check' + resource 'Hunyuan3D status' is specific.
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 when-to-use or when-not-to-use. Among sibling tools, others check availability of different integrations, but no guidance on distinguishing them.
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 full burden. It states the tool returns a message but does not mention side effects (likely none), permissions, or error conditions. For a simple status check, this is acceptable but could be improved by noting it is read-only and has no destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no superfluous words, achieving high conciseness and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status check tool with no parameters and a straightforward function, the description is reasonably complete. However, it lacks mention of error cases (e.g., if Blender is not running) and preconditions (e.g., PolyHaven addon installed), which would enhance completeness given the sibling tools that depend on its result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100% (empty). The description adds value by specifying the output is a message about integration availability, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool checks if PolyHaven integration is enabled in Blender, which is a specific verb-resource pair. It distinguishes from sibling PolyHaven action tools like search_polyhaven_assets and download_polyhaven_asset, though it could be more explicit about the nature of the returned message.
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 that this tool should be used before other PolyHaven operations to verify availability, but it does not explicitly state when to use it vs. alternatives like get_polyhaven_categories, nor does it mention 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 description must carry full burden. It mentions the return type (Image) but lacks details on resolution scaling, viewport coverage, or any side effects. Minimal transparency beyond basic purpose.
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?
Extremely concise: two sentences plus a bullet point. No redundant information, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 optional parameter, no output schema, no annotations), the description is mostly complete. It explains the parameter and return type. Lacks details like scaling behavior, but adequate for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the max_size parameter as 'Maximum size in pixels for the largest dimension', adding meaning beyond the schema's type and default. Could be more precise but effectively clarifies the parameter's role.
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 it captures a screenshot of the Blender 3D viewport, with a specific verb and resource. Distinct from siblings like get_scene_info or get_object_info, none of which involve screenshots.
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, no when-not-to-use, and no prerequisites or context for invocation.
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 mentions scaling behavior and access rights, but does not disclose failure modes, side effects, or whether it is a write operation. Adequate but could be more transparent about error handling and scene impact.
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 relatively concise, with a clear opening sentence and parameter details in bullet points. However, it repeats target_size description twice. Front-loaded but could be slightly more efficient.
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, description states return details (object names, dimensions, bounding box). Covers main points for a simple tool, though lacks handling of invalid UID or existing imports. Sufficient for the context.
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 description adds value. It explains both parameters: uid as unique identifier and target_size with examples for context. Adds meaning beyond the schema's basic type and required field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (download and import), the resource (Sketchfab model), and the identifier (UID). It distinguishes from sibling tools like search_sketchfab_models and get_sketchfab_model_preview, which are search/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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives. No when-not or comparison to siblings like search_sketchfab_models or import_generated_asset. It implicitly assumes usage when a UID is known, but no exclusions 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 provided, so the description must disclose behavior. It only states 'apply' and 'returns a message', omitting details like idempotency, error handling, or effects on existing textures. Minimal behavioral insight.
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?
Very concise: one-line summary followed by a bullet-point parameter list. No extraneous text. Front-loaded purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers basics but lacks details on input formats, error messages, or behavior when object already has textures. Adequate but not thorough.
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 explaining each parameter: object_name as 'Name of the object' and texture_id as 'ID... must be downloaded first'. This adds context beyond the 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 action 'Apply', the resource 'Polyhaven texture', and the target 'object', with a prerequisite. It distinguishes from siblings like download_polyhaven_asset by specifying the prior download 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 includes a prerequisite condition ('must be downloaded first'), but does not explicitly state when to use this tool versus alternatives like download_polyhaven_asset or when not to use it. Usage is implied but not fully guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only says 'Return if the asset has been imported successfully,' lacking details on side effects (e.g., overriding existing objects), prerequisites (must scene be open?), error states, or asynchronous behavior. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence stating purpose followed by a structured parameter list. It wastes no words, though the parameter list could be integrated into a flowing sentence.
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 and no annotations, the description covers purpose and parameter semantics but lacks context on return value structure, error handling, side effects, and whether the import is synchronous. For a low-complexity tool, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning: name defines the scene object name, task_uuid and request_id are explained with their respective modes and source steps. The instruction to only give one is extra guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports an asset generated by Hyper3D Rodin after completion. The verb 'import' and resource 'asset generated by Hyper3D Rodin' are specific. It distinguishes from sibling tools like generate_hyper3d* 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies to use after generation completion and gives guidance on parameter choice based on mode. It explicitly instructs to only give one of task_uuid or request_id. However, it doesn't exclude cases like missing prerequisites or compare with the sibling import_generated_asset_hunyuan.
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 disclose behavior. It states the tool retrieves 'detailed information' but offers no specifics about what properties are returned, whether it is read-only, or any side effects. The description is adequate for a simple query 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 consists of a single, clear sentence with no unnecessary words. It is front-loaded and efficient, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple signature, the description is minimally adequate but vague. It fails to clarify what 'detailed information' encompasses (e.g., object list, scene settings, render properties). Greater specificity would improve completeness without burdening conciseness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema coverage is trivially 100%. The description adds no parameter information, which is acceptable as no parameters exist. Baseline score of 4 is appropriate since no compensation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about the current Blender scene. The verb 'Get' and resource 'scene info' are specific and distinctive from sibling tools like get_object_info (targets objects) and get_viewport_screenshot (targets images).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get scene details) but provides no explicit guidance on when not to use it or how it compares to alternatives like get_object_info. No exclusions or context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is read-only (checks status) and returns a message, but does not disclose whether any side effects or authentication requirements exist. For a simple status check, this is acceptable but not exemplary.
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 with no extraneous information. Every phrase adds value, making it highly efficient.
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 tool is conceptually simple, and the description covers its purpose and return value. It could mention that the operation is read-only, but given no output schema and zero parameters, the explanation is sufficient for an agent to use 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?
There are zero parameters, so the baseline is 4. The description correctly conveys that no input is needed, and no parameter-specific details are required.
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 clear verb ('Check') and explicitly names the resource ('Sketchfab integration enabled in Blender'). It distinguishes itself from sibling status tools like get_polyhaven_status by specifying the tool's domain (Sketchfab).
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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., get_polyhaven_status). However, its purpose is implied by its name and the sibling tools, making it minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses asynchronous behavior (returns job_id, status changes to DONE) and built-in materials. However, it does not detail potential side effects on the Blender scene (e.g., overwriting existing objects).
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, with a clear header, parameter list, and return section. It front-loads the main purpose. Could be slightly more compact but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (async generation, import) and lack of output schema, the description covers purpose, parameters, and return behavior (job_id, status, error). It lacks details on import semantics (e.g., whether it replaces or adds to scene) and how to poll status, but is largely 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 description coverage is 0%, so description compensates well. It clarifies text_prompt as optional and input_image_url as optional with URL format ('local or remote url') and the ability to accept None if only text is used.
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 'Generate 3D asset using Hunyuan3D' and 'import the asset into Blender', using a specific verb and resource. It distinguishes from sibling tools like generate_hyper3d_model_via_text by specifying Hunyuan3D and built-in materials.
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 mentions providing text, image, or both, but does not explicitly state when to use this tool over alternatives (e.g., hyper3d generators or separate import tools). Usage context is implied but lacks exclusions or explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses that the model has built-in materials, is normalized, and returns a success/failure message. However, it lacks details about potential side effects, such as whether the tool blocks until completion, or if it requires network access for FAL_AI mode.
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 introductory statement followed by parameter explanations. It is somewhat lengthy but every sentence adds value. Minor improvement could be to bullet the parameter details more concisely.
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 complexity (generation + import) and no output schema, the description explains the basic process and result. However, it does not clarify how the import step works (e.g., auto-import vs separate tool) or whether the generation is asynchronous, which is implied by the existence of sibling tools for polling status.
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%, so the description must explain parameters. It clearly adds meaning: input_image_paths must be absolute paths and even single image requires a list; input_image_urls similarly; bbox_condition optional with specific format. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 3D asset using Hyper3D from images and imports it into Blender. It distinguishes itself from the text-based sibling (generate_hyper3d_model_via_text) by specifying images as input.
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 when to use input_image_paths vs input_image_urls depending on the Hyper3D Rodin's mode. It also notes that the model is normalized and may need rescaling. However, it does not explicitly state when to prefer this tool over text-based generation or other alternatives.
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 present. Discloses built-in materials, normalized size, and return message. Lacks details on async behavior, processing time, or potential failures, but covers key behavioral traits adequately.
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, front-loaded with purpose, no unnecessary words. Every sentence adds value.
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?
Adequate overall but lacks details on job lifecycle (e.g., polling, blocking). With no output schema and low schema coverage, more guidance on expected behavior 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 coverage is 0% but description compensates by explaining text_prompt as 'short description in English' and bbox_condition as controlling length/width/height ratio. Adds meaning beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Generate 3D asset using Hyper3D by giving description' and specifies import into Blender. It differentiates from sibling tool generate_hyper3d_model_via_images which uses images.
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 when-to-use guidance (text to 3D generation) and describes optional bbox_condition parameter. Does not explicitly state when not to use, but context of siblings implies alternatives are available.
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 it returns a thumbnail as an Image, implying a read-only operation without side effects. However, it lacks details on error handling, performance, or potential issues like invalid UID, which would be important for safe invocation given the absence of annotations.
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 sentences and a parameter list, efficiently conveying the tool's action, use case, and parameter source. There is no redundant information, and key points are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one parameter and no output schema, the description adequately explains what it does and what it returns (thumbnail as Image). However, it could be more specific about the image format or how it is returned, but it is sufficient for basic usage.
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 for the 'uid' parameter by stating it is obtained from search_sketchfab_models, which is not present in the input schema. It provides crucial source context, though it omits format specifics like string length or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a preview thumbnail of a Sketchfab model by its UID', specifying the verb, resource, and method. It distinguishes this tool from siblings like search_sketchfab_models and download_sketchfab_model by focusing on visual confirmation before download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using it to 'visually confirm a model before downloading', providing clear context for its use. It does not explicitly list alternatives or when not to use, but the context implies it is a preliminary step to download_sketchfab_model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes polling nature, expected statuses, and final states, but omits details like rate limits, timeouts, or retry behavior. The behavior is adequately described for a basic polling tool.
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 per mode, but it is somewhat verbose. Each sentence adds value, but consolidating could improve readability. Front-loading the purpose is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides return value interpretation and final states. It covers the two modes adequately but could add guidance on error handling for non-standard statuses. Overall sufficient for the tool's complexity.
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%, so the description must compensate fully. It does so by explaining each parameter (subscription_key for MAIN_SITE, request_id for FAL_AI) and their source from the generate step, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a Hyper3D Rodin generation task is completed. It distinguishes between two modes (MAIN_SITE and FAL_AI) with different parameters and statuses, specifying the verb 'poll' and resource '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 explains when to use the tool (after generation) and how to interpret statuses, with clear polling logic. However, it does not explicitly compare to sibling polling tools like poll_hunyuan_job_status or get_hyper3d_status, which could help an agent choose.
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 provided, so description fully carries the burden. Discloses status values (DONE, RUN), return format (ResultFile3Ds with ZIP path), and polling behavior. Lacks details on rate limits or auth needs but is solid overall.
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?
Description is informative but slightly redundant, repeating status meanings and return format. Could be more concise without losing clarity.
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 one parameter and no output schema, the description explains return values, status conditions, and polling nature. Lacks detail on error states or timeout, but adequately comprehensive for a polling tool.
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?
Only parameter job_id has no schema description (0% coverage), but the description adds that it is the job_id from the generate model step, providing essential context beyond the schema's title and default.
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 the Hunyuan3D generation task is completed, using a specific verb (check/completion) and resource (Hunyuan3D task). It distinguishes from siblings like poll_rodin_job_status by naming the specific 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?
Explicitly states this is a polling API and to only proceed when status is final. Provides context on using job_id from the generation step. Does not explicitly list when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the return value ('if the asset has been imported successfully') but does not disclose side effects (e.g., scene modification) or error behavior. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence stating the core purpose, followed by a well-structured parameter list and a one-line return statement. Every sentence adds value with no 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's simplicity (2 required params, no output schema), the description covers purpose, parameter roles, usage timing, and return type. It is sufficiently complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains both parameters: 'name' as the object name in the scene, and 'zip_file_url' as the URL from the generate model step. This adds essential meaning beyond the schema's type/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 clearly states it imports an asset generated by Hunyuan3D after the generation task is completed, using specific verb 'Import' and resource 'asset generated by Hunyuan3D'. It distinguishes from sibling tools like import_generated_asset, which likely handles other generators.
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 'after the generation task is completed', providing clear context for when to use. It does not mention alternatives or exclusions, but the name and context imply the tool is specific to Hunyuan3D assets, giving adequate guidance.
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/silwings1986/blender-mcp/badges/card.svg)](https://glama.ai/mcp/servers/silwings1986/blender-mcp)

Score Badge

Copy to your README.md:

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

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