blender-mcp

by Vertiiii

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: v0.1.0
Disambiguation5/5
Each tool targets a distinct function: asset downloads from different sources, info retrieval, search, status checks, code execution, and polling. There is no overlap; even similar tools like generate_hyper3d_model_via_images and generate_hyper3d_model_via_text differ in input type.
Naming Consistency5/5
All tool names follow the snake_case verb_noun pattern consistently (e.g., download_polyhaven_asset, get_scene_info). Naming is predictable and easy to understand.
Tool Count5/5
With 17 tools, the server covers a broad but focused scope for a Blender integration: asset imports, scene/object info, search, status checks, and general code execution. The count feels well-balanced for the domain.
Completeness3/5
The tool set covers asset importing and basic scene information but lacks direct tools for object manipulation, deletion, or material editing beyond textures. The presence of execute_blender_code acts as a catch-all, but for a high-level surface, significant operations are missing.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI 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 fully convey behavioral traits. It states 'Returns a formatted list' but does not disclose whether the tool is read-only, has side effects, handles pagination, or has any limitations. The name implies searching, but lack of explicit transparency is a gap.
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 purpose. The parameter list is formatted clearly with one line per parameter. No unnecessary sentences. However, the return description could be integrated more succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no output schema, the description covers the basic usage and return format. It explains the parameters sufficiently for a search tool. However, it lacks details on error handling, what 'formatted list' entails, or any constraints on categories. It is minimally viable but not comprehensive.
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%, and the description adds meaning to all parameters, e.g., 'query: Text to search for', 'categories: Optional comma-separated list', 'count: Maximum number of results', and 'downloadable: Whether to include only downloadable models'. Default values are noted. While not exhaustive, this significantly aids understanding beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search for models on Sketchfab', providing a specific verb and resource. However, it does not explicitly distinguish from sibling tools like 'search_polyhaven_assets' or 'download_sketchfab_model', which could cause confusion about when to use this tool vs. others.
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. It does not specify that this tool is for searching only and that downloads should be performed with 'download_sketchfab_model'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states that it gets information, implying a read-only operation, but does not explicitly confirm safety, side effects, or what 'detailed information' includes. The agent is left to assume it is non-destructive without confirmation.
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 very concise, consisting of a single sentence and a parameter list. Every word contributes meaning, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a simple information retrieval tool. It does not describe what 'detailed information' includes (e.g., properties, transform, modifiers), nor does it state prerequisites (e.g., object must exist) or behavior if the object is not found. Missing output schema makes this more critical.
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 input schema has no descriptions for its only parameter. The tool description provides a minimal description ('The name of the object to get information about'), which adds value. However, it lacks details like case sensitivity, format, or constraints. Given low schema coverage, the description compensates minimally.
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 detailed information about a specific object in the Blender scene.' The verb is specific (get) and the resource is well-defined (object information in Blender scene). It distinguishes itself from siblings like get_scene_info and other asset-specific getters.
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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives like get_scene_info or other getters. There is no mention of prerequisites or contextual cues for selection.
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 disclose behavioral traits. It mentions executing arbitrary code but does not disclose potential side effects (e.g., crashing Blender, modifying scene permanently), security implications, or return values. The step-by-step advice is a usage tip, not a behavioral disclosure.
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 only two sentences, concise and front-loaded. However, it could be slightly more structured by separating the purpose from the guidance. It earns high marks for brevity without missing essential elements.
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 has one parameter and no output schema, the description provides the core purpose. However, it lacks information on error recovery, return type, or how the code interacts with Blender state. The step-by-step advice partially offsets this by suggesting safe usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It only rephrases the parameter name ('code: The Python code to execute') without adding format, length, or constraint details. No examples or additional context are given.
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 'execute' and the resource 'arbitrary Python code in Blender'. It distinguishes this tool from all sibling tools, which are focused on downloading, generating, or querying assets, none of which involve arbitrary 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for running Python code in Blender but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The step-by-step hint is procedural but not a replacement for when-to-use context.
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?
Annotations are absent, so the description carries the full burden. It implies a read operation by saying 'Check if... integration is enabled', but does not explicitly state it is non-destructive. The instruction to 'sliently remember' the key type adds a behavioral quirk without clarifying implications, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short with two sentences, avoiding unnecessary words. However, the second sentence is cryptic and may confuse agents, slightly reducing clarity. Still, it is relatively concise.
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 parameters and no output schema, the description covers the basic purpose adequately. However, it omits potential error conditions, return format details, and the meaning of 'key type'. For a simple status check, it is marginally complete but leaves open questions.
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, so the schema is complete. The description adds no parameter details, which is acceptable since there are none. Baseline score of 4 is appropriate.
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 checks if Hyper3D Rodin integration is enabled and returns a message about availability. It uses a specific verb-resource pair ('Check if Hyper3D Rodin integration is enabled'). However, it does not differentiate from sibling status-check tools like get_sketchfab_status or get_polyhaven_status, missing explicit distinction.
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. There is no mention of prerequisites, when-not-to-use, or scenarios where other tools would be preferred. The cryptic note about 'key type' does not serve as practical usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states that the tool 'Returns a list of matching assets with basic information' but does not disclose other behaviors such as rate limits, authentication requirements, or whether the operation is read-only. Minimal behavioral information is given.
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 brief and functional, consisting of two sentences for the overview and a structured list of parameters. It is front-loaded with the main purpose and uses efficient language. However, it could be slightly tighter by integrating the parameter details into a more cohesive format.
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 low parameter count (2) and absence of annotations and output schema, the description provides adequate but not comprehensive context. It covers the core functionality and parameter types but lacks details on default values (e.g., asset_type defaults to 'all'), the structure of returned data, and potential errors or limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add meaning. It explains 'asset_type' with possible values (hdris, textures, models, all) and 'categories' as a comma-separated list. This adds basic semantics beyond the schema, but does not enumerate possible categories or provide format constraints, achieving only moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for assets on Polyhaven with optional filtering.' It distinguishes from siblings by referencing Polyhaven, while 'search_sketchfab_models' targets a different source. The verb 'search' combined with 'assets' and 'optional filtering' provides a specific and actionable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and mentions optional filtering, but it lacks guidance on when to use this tool versus siblings like 'search_sketchfab_models' or 'get_polyhaven_categories.' No explicit context for when-not-to-use or alternatives 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?
With no annotations, the description only mentions return type (message) and prerequisites. It does not disclose side effects (e.g., scene modification), idempotency, rate limits, or error handling beyond success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and presents action first, then parameter and return. It could group the prerequisite line more efficiently, but overall is well-structured and not verbose.
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, description covers the basic action and prerequisites but lacks usage guidance and behavioral context, making it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Coverage is 0%, so description must compensate. However, it merely restates 'uid: The unique identifier of the Sketchfab model' from the schema without adding format, examples, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it downloads and imports a Sketchfab model by UID, distinguishing it from sibling tools like search_sketchfab_models 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies prerequisites (model must be downloadable, proper access rights) and return value, but does not explicitly mention when to use this tool over alternatives or that the UID likely comes from search_sketchfab_models.
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 for behavioral disclosure. It only states the tool 'gets a list', implying read-only, but does not disclose any traits like pagination, rate limits, data freshness, or return format. The description is minimally transparent.
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: two sentences plus a parameter list. It front-loads the purpose and uses minimal, direct language. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameter meaning adequately, but lacks detail on the return format (e.g., is it a list of strings or objects?). Given no output schema, more completeness would be beneficial. However, for a simple category list, it meets minimum viability.
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 to the sole parameter 'asset_type' by listing the allowed values (hdris, textures, models, all) and explaining its purpose, which is absent from the schema. Schema coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the resource (list of categories), and the context (for a specific asset type on Polyhaven). It distinguishes the tool from sibling tools that search or download assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like search_polyhaven_assets. It implies usage for fetching category lists but does not state prerequisites or when-to-use/not-to-use conditions.
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?
Without annotations, the description must disclose behavioral traits. It mentions returning an Image but does not specify if the operation is read-only, whether it requires an active viewport, or any side effects. It also lacks details like performance impact or error conditions. The transparency is minimal beyond the obvious.
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 very concise, with only two sentences: one for purpose and one listing the parameter. It is front-loaded with the main action and organized clearly. Every sentence is necessary and no extraneous information is present.
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 low complexity (single parameter, no output schema), the description is mostly adequate but missing some important context. It does not specify what 'Image' means (e.g., data URL, binary, path), nor does it mention that the screenshot is of the 3D viewport only (not UI elements). These gaps could confuse an agent.
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 only parameter, max_size, is described as 'Maximum size in pixels for the largest dimension (default: 800)'. This adds meaning beyond the input schema, which only declares type and default. The description clarifies that it applies to the largest dimension, helping the agent understand the scaling behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot of the current Blender 3D viewport. It uses a specific verb ('Capture') and resource ('screenshot of the current Blender 3D viewport'), which distinguishes it from all sibling tools that deal with downloading assets, executing code, or getting 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 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. It does not mention any prerequisites, limitations, or contexts where another tool might be more appropriate. For example, it could note that this is for visual inspection while get_scene_info is for data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions built-in materials and normalized size, but lacks details on success/failure conditions, side effects (e.g., overwriting scenes), async behavior, or required dependencies (e.g., Blender running). The return value is minimally described as a message.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear main sentence followed by bullet-like points for key traits and parameters. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (text-to-3D generation and import), the description lacks critical context: import location/naming, whether the process is synchronous or async (hinted by sibling tools like 'get_hyper3d_status'), prerequisites, and error handling beyond a generic success/failure message. No output schema compounds this gap.
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 meaningful context to both parameters: text_prompt should be a short English description, and bbox_condition is an optional list of three floats controlling length/width/height ratio. This goes beyond the schema's type-only definitions. Schema coverage is 0%, so this compensation is important; however, more specifics like default values or ranges for bbox_condition would be helpful.
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: generating a 3D asset via Hyper3D from a text description and importing it into Blender. It distinguishes from sibling tools like 'generate_hyper3d_model_via_images' which uses images instead of text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for text-based generation and mentions an optional bbox condition, but does not explicitly state when to use this tool over alternatives or exclude certain scenarios. Sibling tools like 'generate_hyper3d_model_via_images' suggest image-based generation, but no comparison 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 exist, and the description only states 'Get detailed information' without disclosing what 'detailed' includes, potential cost, or prerequisites. It simply indicates a read operation without 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 a single sentence with no extraneous words, efficiently conveying the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fails to hint at return values, leaving the agent uncertain about what 'detailed information' includes. It is not fully informative for invocation decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description adds clarity that no input is needed. It does not require additional parameter elaboration beyond stating the purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about the current Blender scene', distinguishing it from siblings like get_object_info which focus 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when scene-level info is needed, but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives like get_object_info for object-specific data.
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 for behavioral disclosure. It explains that the tool downloads and imports into Blender, and returns a success/failure message. However, it omits details like whether it overwrites existing files, the download location, or what exactly 'import' means (e.g., adds to scene, appends to file). Some behavior is covered, but gaps remain.
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 (two sentences plus a bullet-style parameter list) and effectively front-loaded with the purpose. Every sentence serves a purpose. It could be slightly more streamlined, but it is well-structured for quick comprehension.
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 lack of output schema and the 0% schema coverage, the description provides adequate parameter semantics and return type. However, it misses important context: prerequisites (Blender running, internet), potential side effects (e.g., file system changes), and handling of errors (e.g., invalid asset_id). Additionally, it does not clarify how this tool interacts with siblings like import_generated_asset. Overall, it is functional but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema. It explains each parameter: asset_id, asset_type with example values ('hdris, textures, models'), resolution with examples ('1k, 2k, 4k'), and file_format with type-specific examples. This compensates fully for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Download and import' and the resource 'a Polyhaven asset into Blender.' This distinguishes it from sibling tools like search_polyhaven_assets (search) and get_polyhaven_status (status), as well as other download tools for different sources (e.g., download_sketchfab_model). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 (e.g., search_polyhaven_assets to find assets first, or get_polyhaven_status to check availability). It also does not mention prerequisites such as having Blender open or an active internet connection, nor does it specify 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 are provided, so the description must fully convey behavioral traits. It mentions returning a success/failure message but does not disclose effects like overwriting existing textures, error conditions for missing objects or undownloaded textures, or any destructive potential. This leaves significant gaps for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with a clear structure: purpose statement followed by a parameter list. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 mandatory parameters and no output schema, the description explains inputs and return value. However, it could mention the prerequisite of having the texture downloaded in the main description (currently only in parameter info) and potential errors. Still mostly 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?
Schema coverage is 0%, but the description adds clear parameter semantics: object_name is 'Name of the object to apply the texture to', texture_id is 'ID of the Polyhaven texture to apply (must be downloaded first)'. This adds meaning beyond the schema's type and title, compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a previously downloaded Polyhaven texture to an object. The verb 'apply' and resources (Polyhaven texture, object) are specific, distinguishing it from tools like download_polyhaven_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the texture must be downloaded first, but does not explicitly state when to use this tool vs alternatives, such as other texture application methods or prerequisites. No guidance on exclusions or conditional use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions built-in materials, normalized size (with re-scaling suggestion), and that it imports into Blender. However, it does not disclose potential failures, time requirements, or async behavior (despite sibling poll_rodin_job_status hinting at async).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core purpose, and uses structured bullet points for parameters. Every sentence adds value without repetition.
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 generation tool with two modes and import step, the description covers basics but omits how to determine the current mode, that generation may be asynchronous (given sibling polling tool), and the return value is vague ('message indicating success or failure'). No output schema exacerbates the gap.
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 significant meaning: absolute paths requirement, list wrapping for single images, bbox_condition length 3 and ratio control. These details are not in the schema, making the description valuable.
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+resource: 'Generate 3D asset using Hyper3D by giving images' and notes import into Blender. It distinguishes from siblings like generate_hyper3d_model_via_text (text input) and import_generated_asset (import already generated).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that only one of input_image_paths or input_image_urls should be given depending on the Hyper3D Rodin's current mode, but does not explicitly say when to use this tool over alternatives or provide when-not conditions. The mode distinction is only partially explained.
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, description carries burden. It states returns a message about availability but doesn't detail format or possible responses. Adequate for a simple check.
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 concise sentences, no wasted words. Front-loaded with 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?
For a zero-parameter status check, description adequately covers purpose and outcome. No output schema but return type is implied.
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, and schema coverage is 100%. Description adds nothing extra but baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Check') and resource ('PolyHaven integration enabled status'). It distinguishes from sibling tools like download_polyhaven_asset or search_polyhaven_assets by focusing on status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance when to use versus alternatives. Usage is implied as a preliminary check before other PolyHaven operations, but not stated.
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 the description must carry the burden. It discloses the import action, required parameters, and return value (success boolean). However, it does not mention side effects (e.g., adding to scene), idempotency, or error conditions, leaving some gaps.
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 reasonably concise with a clear purpose statement followed by parameter explanations in a list format. It is well-structured but could be slightly shorter 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 3 parameters and no output schema or annotations, the description covers the purpose, parameter usage with mode distinction, and return value. It could elaborate on what 'successfully' means (e.g., boolean) but is fairly complete for a straightforward import 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?
The schema has 0% description coverage, so the description compensates fully. It explains that 'name' is the object's scene name, and distinguishes task_uuid (for MAIN_SITE mode) from request_id (for FAL_AI mode), adding essential 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 the tool imports an asset generated by Hyper3D Rodin after generation completion. It uses a specific verb and resource, and distinguishes from sibling tools like generate_* and get_*.
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 instructs to give only one of task_uuid or request_id based on the Rodin mode, providing clear usage context. It lacks explicit when-not-to-use or alternatives, but the guidance is strong and immediate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the polling behavior, the status values for each mode, and the condition for completion. It does not cover permissions or rate limits, but the core behavior is well described.
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 well-structured with separate sections for each mode and clear front-loading (first sentence states purpose). However, it repeats 'This is a polling API' for each mode and could be more concise overall.
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 explains return values (list of statuses for MAIN_SITE, single status for FAL_AI) and how to interpret them. It covers completion, failure, and in-progress states, but lacks details on error handling or timeout expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining that request_id is for FAL_AI mode and subscription_key is for MAIN_SITE mode, and that they are obtained from the generate step. This adds meaningful context 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 it checks if the Hyper3D Rodin generation task is completed, distinguishing between two modes (MAIN_SITE and FAL_AI) with specific parameters and statuses. This is a specific verb-resource pairing that differentiates it from sibling tools like get_hyper3d_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 this tool (after generating a model) and that it is a polling API to be polled until final status. It does not explicitly state when not to use it or mention alternatives, but the context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clearly states the tool is a read-only status check, returning a message. No side effects or hidden behaviors are hinted at, but for a simple check this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence front-loads the purpose, second confirms the return value.
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 zero parameters, no output schema, and straightforward behavior, description is complete. It explains what the tool checks and what it returns.
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 (0 params, schema coverage 100%). Baseline for no parameters is 4; description adds no param info because none 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?
Description clearly states verb 'Check', resource 'Sketchfab integration', and outcome 'Returns a message indicating whether Sketchfab features are available'. Differentiates from sibling tools like download_sketchfab_model and search_sketchfab_models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 guidance. Usage is implied as a prerequisite check before Sketchfab operations, but no alternatives or exclusions are mentioned.
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/Vertiiii/blender-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Vertiiii/blender-mcp)

Score Badge

Copy to your README.md:

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

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