BlenderMCP

by Gorav22

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.1.3
Disambiguation5/5
Each tool has a clearly distinct purpose: downloading assets, generating models via images or text, checking statuses, getting scene/object info, searching, and applying textures. Even overlapping functions like generate_hyper3d_model_via_images and via_text are differentiated by input type.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., download_polyhaven_asset, execute_blender_code), but there are minor deviations like 'poll_rodin_job_status' vs 'get_hyper3d_status' and mixed use of 'get_', 'search_', 'generate_'. The pattern is still recognizable and readable.
Tool Count5/5
With 13 tools, the server covers Polyhaven integration (download, search, categories, status, set texture), Hyper3D generation (images/text, status, poll, import), and basic scene introspection. This is well-scoped for a Blender MCP server without being excessive or anemic.
Completeness4/5
The tool surface covers the core workflows for external asset integration (Polyhaven, Hyper3D) and provides code execution for flexibility. Minor gaps exist, such as no dedicated tool for deleting assets or listing objects, but these can be addressed via execute_blender_code.
Average 3.7/5 across 13 of 13 tools scored. Lowest: 2.9/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, and the description does not disclose any behavioral traits such as caching, rate limits, side effects, or output details. For a tool without annotations, this 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?
The description is concise and front-loaded with the main purpose. It includes a parameter list with no extraneous words. It could be improved with bullet points but is acceptable.
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 list tool with one parameter and no output schema, the description covers the basic functionality. However, it lacks information about the output format or whether the list is complete, which could affect agent's understanding.
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 by listing possible values (hdris, textures, models, all) which are not in the schema (no enums). However, with 0% schema coverage, it only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'categories' with asset type parameter. It implicitly differentiates from sibling tools like search or download by specifying a focused list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_polyhaven_assets. The description only states what it does, not when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose important behavioral traits such as potential side effects, error handling, or safety implications of executing arbitrary code. The advice to break code into chunks hints at reliability 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a parameter list. It is well-structured and clearly presents the parameter, though it could be slightly more organized.
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 that the tool executes arbitrary code, the description lacks completeness. It omits context about the Blender environment, error behavior, return values, and any constraints. No output schema 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?
With 0% schema description coverage, the description compensates by listing the 'code' parameter and stating 'The Python code to execute'. This is basic but adequate for a single string 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 'Execute arbitrary Python code in Blender', which is a specific verb and resource. It distinguishes itself from sibling tools that focus on downloading assets, generating models, or retrieving scene info.
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 it into smaller chunks' but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it. The hint is minimal.
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 all behavioral traits. It only states it downloads and imports, returning success or failure. Missing details: whether it overwrites existing assets, requires internet access, handles errors (e.g., invalid asset_id), or any side effects on the Blender scene.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with a clear verb-action and a parameter list. It avoids unnecessary words. However, the parameter list is somewhat redundant given the input schema, though it adds value due to zero schema coverage. Slightly better structuring (e.g., using bullet points) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers the basic purpose and parameter meanings. Missing elements: usage prerequisites (e.g., Blender scene must be open?), error scenarios, and behavior when resolution or format is unsupported. Adequate but has clear 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 coverage is 0%, so the description is the sole source for parameter meaning. It explains each parameter and provides examples (e.g., 'hdris, textures, models' for asset_type). However, it lacks explicit valid values or format constraints, and does not clarify default behavior (e.g., resolution default '1k' is in schema but not described).
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 that the tool downloads and imports a Polyhaven asset into Blender. It lists asset_id, asset_type, resolution, and file_format, making the function obvious. It is distinct from sibling tools like search_polyhaven_assets and get_polyhaven_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?
The description provides no guidance on when to use this tool versus alternatives like search_polyhaven_assets (for discovery) or import_generated_asset (for importing custom assets). There is no mention of when not to use it, such as when the asset is already present or if offline.
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, and the description only states it returns a success/failure message. It lacks details on side effects (e.g., replacing existing textures), potential errors, or performance implications. For a mutation tool, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences plus a parameter list. The main action is front-loaded. Minor fluff could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description mentions return value. However, it does not explain the prerequisite relationship with 'download_polyhaven_asset' or what 'apply' entails (e.g., material creation).
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%, but the description adds basic meaning: 'object_name' is the name of the object, 'texture_id' is the ID of a pre-downloaded texture. No additional format or constraints are provided.
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 'Apply a previously downloaded Polyhaven texture to an object,' with specific verb and resource. It distinguishes itself from sibling tools like 'download_polyhaven_asset' and 'search_polyhaven_assets' by focusing on the application 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?
Description mentions the prerequisite 'must be downloaded first' but does not provide explicit when-to-use or when-not-to-use guidance, nor comparisons with other similar tools like 'import_generated_asset'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that the tool checks status (read-like) but also instructs to 'silently remember it,' implying unintended statefulness or side effects. This adds behavioral context but is ambiguous and potentially misleading.
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 short but contains a confusing second sentence about silently remembering the key type. This adds unnecessary ambiguity and could be removed or clarified for better 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?
Given no output schema and no parameters, the description is mostly adequate for a simple status check. However, it fails to provide context on when to use this tool among Hyper3D siblings, and the odd instruction about remembering state is unexplained, leaving 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?
The tool has no parameters, so parameter semantics are trivially covered. The description adds no further meaning, but none is needed. Baseline is high due to missing parameter complexity.
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 tool name and description clearly state it checks if Hyper3D Rodin integration is enabled in Blender. It also mentions returning a message about availability, distinguishing it from sibling tools like generate_hyper3d_model_via_images 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 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. With siblings like generate_hyper3d_model_via_text and poll_rodin_job_status, the description should clarify that this is a precondition check before generation or status polling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states 'Get detailed information', implying read-only behavior without detailing any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that communicates the purpose efficiently with no unnecessary 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?
While the description is adequate for a tool with no parameters or output schema, it lacks specificity about what 'detailed information' includes, leaving the agent uncertain about the return 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?
The tool has zero parameters and schema coverage is 100%, so the description does not need to add parameter details. Baseline of 4 is appropriate.
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' and the resource 'detailed information about the current Blender scene', distinguishing it from the sibling 'get_object_info' which focuses on individual objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_object_info'. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions the return type ('list of matching assets with basic information') but omits side effects, authentication needs, rate limits, or whether the search is read-only. This is inadequate for a tool with no annotation safety net.
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, with a clear front-loaded purpose statement and a structured parameter list. Every sentence is informative, and there is no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional parameters, no output schema), the description is minimally sufficient. However, it lacks details on pagination, result fields, or error handling, which would improve usability for an agent without context.
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 only provides types and defaults (0% schema coverage). The description adds critical meaning: allowed values for 'asset_type' (hdris, textures, models, all) and clarifies 'categories' as a comma-separated list. This significantly enhances parameter understanding 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 ('Search for assets on Polyhaven') and identifies the resource ('assets on Polyhaven'). It also mentions optional filtering, distinguishing it from sibling tools like 'get_polyhaven_categories' and 'download_polyhaven_asset'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus its siblings (e.g., for broad search vs. category browsing). It lacks context about prerequisites or scenarios where alternatives are preferred.
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 asset has built-in materials and normalized size, but is ambiguous about whether import into Blender is automatic or requires a separate call (sibling import_generated_asset exists). It does not disclose async behavior, failure modes, or idempotency, leading to potential confusion.
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 with about 9 lines, but includes some redundancy (e.g., separate sentences about built-in materials and normalized size). The core purpose is front-loaded, but parameter details could be integrated more compactly.
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 (3 parameters, no output schema, no annotations), the description covers generation and parameter usage. However, it lacks details on async behavior (despite a sibling poll_rodin_job_status), return value specifics, and whether import is automatic. Integration hints with sibling tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant meaning: it explains input_image_paths as absolute paths (required in MAIN_SITE mode), input_image_urls as URLs (required in FAL_AI mode), and bbox_condition as controlling length/width/height ratio. It also clarifies that single images must be wrapped in a list.
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 sibling tool generate_hyper3d_model_via_text, which uses text 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 specifies when to use input_image_paths vs input_image_urls based on Hyper3D Rodin's mode, and notes that only one should be given. It also mentions re-scaling after generation. However, it does not explicitly contrast with alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get detailed information' strongly implies a read-only operation with no side effects, it does not explicitly state this or mention any other behavioral traits (e.g., no modifications, no permissions needed). The description is adequate for a simple read tool 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 short and efficient: two sentences that state the purpose and list the parameter. It is front-loaded with the main functionality and contains no superfluous information. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the absence of an output schema, the description could have hinted at what 'detailed information' includes (e.g., position, dimensions, materials). It also does not reference any prerequisites or context needed. The description is minimal but covers the essential input, leaving the agent to infer output 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?
Schema description coverage is 0%, so the description must compensate by explaining the parameter. It states that 'object_name' is 'The name of the object to get information about,' which adds context beyond the schema's type and title. For a single, simple parameter, this is sufficient to guide the agent on how to use 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's purpose: 'Get detailed information about a specific object in the Blender scene.' It uses a specific verb ('get') and resource ('object'), and distinguishes itself from sibling tools like 'get_scene_info' (scene-level) and 'execute_blender_code' (code execution).
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 its alternatives. For example, it does not mention that 'get_scene_info' should be used for scene-level information, or that 'execute_blender_code' might be needed for more complex queries. The description simply states what the tool does without any conditional or comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It notes the tool returns a message indicating availability, but does not detail side effects, permissions, or response format. For a simple read-only check, this is adequate but not thorough.
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 two short, clear sentences with no unnecessary words. It is front-loaded with the main action and directly communicates the purpose and return value.
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 has no parameters, no output schema, and a simple operation, the description is reasonably complete. It covers what the tool does and what it returns. It could optionally mention that it is a lightweight query, but is sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. According to guidelines, a baseline score of 4 is appropriate when no parameters exist, as the description cannot add parameter-level detail 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 PolyHaven integration status in Blender, with a specific verb ('Check') and resource ('PolyHaven integration'). This distinguishes it from sibling tools like download_polyhaven_asset or search_polyhaven_assets, 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 Guidelines3/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 versus alternatives. It is implied as a preliminary check before using other PolyHaven features, but no explicit guidance is given. A sentence like 'Use this before downloading assets to verify availability' would improve clarity.
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 that the asset has built-in materials, normalized size (suggesting post-generation re-scaling), and that it imports into Blender. Missing details like time duration or side effects, but these are reasonable omissions.
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?
Three tight sentences plus parameter descriptions. Every sentence adds value: purpose, material info, normalization hint. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 params and no output schema, the description covers key aspects: generation process, importing, materials, size. Missing details like typical generation time or error messages, but these are not critical 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?
Schema coverage is 0%, so description compensates well: text_prompt is 'short description...in English', bbox_condition is 'list of floats of length 3 controlling ratio between Length, Width, Height'. This adds essential context beyond the schema's type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate 3D asset using Hyper3D by giving description' and 'import the asset into Blender'. It specifies verb and resource, and distinguishes from siblings 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 by stating the text prompt parameter is required and mentions optional bbox_condition. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to use image-based generation) or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return value (success/failure) but does not disclose side effects, auth requirements, or potential errors. Without annotations, more detail would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then parameter details. Though efficient, the list format could be slightly more concise.
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?
Covers the key context: when to call, parameter selection, and return status. Lacks handling of edge cases or error states, but adequate for the task.
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?
With 0% schema coverage, the description thoroughly explains each parameter and the mutual exclusivity condition, 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 imports an asset from Hyper3D Rodin after generation completes, distinguishing it from generation and status-check siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates when to use ('after generation task is completed') and specifies parameter selection based on mode, but lacks explicit alternatives or when-not-to-use guidance.
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 carries full burden. It discloses return format (list of status for MAIN_SITE, single status for FAL_AI), status meanings, and when to consider task complete or failed. Could mention idempotency or side effects, but behavior is well-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?
Well-structured with a clear introductory sentence and two mode-specific sections. Slightly verbose (could merge common parts), but each sentence adds value. Front-loaded purpose.
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 covers return values, status meanings, and failure conditions. It lacks polling interval advice or typical latency, but is otherwise complete for a polling tool. Mode-specific details add thoroughness.
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 description adds full meaning. It explains 'subscription_key' and 'request_id' as coming from the generate step, and clarifies conditional usage per mode. This compensates completely 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 'Check if the Hyper3D Rodin generation task is completed' with specific verb and resource. It distinguishes two modes (MAIN_SITE vs FAL_AI) and differentiates from sibling tools like 'get_hyper3d_status' by focusing on polling completion 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?
Provides explicit context for when to use the tool: after the generate model step. Explains which parameter to use for each mode and how to interpret statuses. Lacks explicit exclusions or alternative tool recommendations, but the polling guidance is clear.
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/Gorav22/Blender-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Gorav22/Blender-mcp)

Score Badge

Copy to your README.md:

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

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