blender-control-mcp

by parkspark

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 addresses a distinct resource and action. Read-only tools (scene.inspect, material.list) are clearly separated from write operations (apply_material, transform, add_modifier, set_smooth_shading, export), and no two tools overlap in purpose. An agent could select the correct tool without ambiguity.
Naming Consistency4/5
Tools follow a consistent <domain>.<action> pattern using dots (e.g., scene.inspect, asset.transform), but action verbs vary in style (e.g., 'apply_material' vs 'transform' vs 'export'). This is a minor inconsistency, but the pattern is predictable and readable.
Tool Count5/5
With 7 tools, the server is well-scoped for asset inspection, material editing, transformations, modifiers, shading, and export. Each tool serves a clear purpose without redundancy or bloat, fitting comfortably in the ideal 3-15 range.
Completeness3/5
The surface covers common asset editing workflows (inspect, modify, export), but lacks removal operations such as deleting objects, removing modifiers, or changing material assignments. These gaps could cause dead ends in more complex pipelines, though core workflows are functional.
Average 3.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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 Apache 2.0.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context beyond that: it explains the node-linked behavior and explicitly states 'The source file is never modified,' reinforcing the read-only guarantee. It also clarifies why node-link status matters. This is above the baseline of simply relying on annotations.
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 the core purpose in the first sentence and supplementary behavior in the second. It does not waste words, and the critical info is front-loaded. Minor structural improvement could be separating the 'never modified' statement into its own sentence, but it is already clear.
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 output schema is present, so return format is covered. However, the input parameter is completely unexplained, which is essential for correct invocation. The description also leaves ambiguity about whether it lists all materials or only those with Principled BSDF shaders. For a tool with one required parameter and no schema description, this is a significant completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter input_path has 0% schema description coverage, and the description does not mention it at all. An agent has no clue what input_path should be (likely a file path, but the format or meaning is undefined). Since the description is the only place to compensate for the missing schema detail, this is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists materials and specific Principled BSDF properties (Base Color, Roughness, Metallic, Alpha). It also reports node-link status for Base Color. The verb 'list' is precise, and the resource and fields are named, making the purpose unambiguous and distinguishable from siblings like apply_material or export.
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 it is a read-only inspection tool but does not explicitly state when to use it versus alternatives like scene.inspect or asset.apply_material. It provides context about the node-linked override but lacks clear 'use this when' or 'use this instead' guidance. The safer read-only nature is inferred but not stated as a selection criterion.
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?
Annotations are all false (no hints), so the description carries the full burden. It discloses that the input is never overwritten and outputs go to a unique job subfolder, adding non-destructive context. It also implies a constrained modification ('only allow-listed'). This goes beyond annotations and is useful for an agent deciding to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero fluff. The core action is front-loaded, and critical constraints (target, formats, non-destructive behavior) are packed efficiently. Every clause adds value; no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no schema descriptions, and no helpful annotations, the description needs to be thorough. It covers key aspects (target, base_color, scalars, non-destructive output) but leaves ambiguity about which Principled BSDF values are 'allow-listed' and what happens for unspecified parameters. It also doesn't mention output file naming. The output schema exists, so return values are covered, but the description is not complete enough for an agent to fully predict behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains target (all, material name, or object name), base_color (normalized RGB/RGBA), and scalar values (0..1). However, it does not elaborate on input_path, output_directory, or the individual scalar parameters (alpha, metallic, roughness) by name, nor clarify their optionality/default null. It covers some parameters but not all, so it's partial.
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 states a clear action: 'Change only allow-listed Principled BSDF values and create new GLB, BLEND, and FBX files.' This specifies the verb, resource, and output format. It is distinct from sibling tools like material.list (listing) and asset.transform (geometry), though it doesn't explicitly name alternatives. The mention of 'only allow-listed' adds specificity.
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 provides parameter-level guidance (target syntax, base_color format, scalar range) and implies the tool is for modifying materials, but it does not explicitly state when to use this tool versus alternatives or exclusions. No direct comparison to siblings is given. This is adequate but not explicit.
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?
The description discloses concrete side effects beyond the annotations: it creates new GLB, BLEND, and FBX files in a unique job subfolder and never overwrites input. This adds safety-relevant behavioral context that the sparse annotations do not provide.
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 compact sentences front-load the core action and scope, then add output and non-destructive behavior. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three required string parameters and zero schema descriptions, the description gives a usable overview but leaves important details ambiguous, such as exact target syntax, accepted input formats, and precise output_directory behavior. The presence of an output schema reduces the need to describe return values.
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 partially compensates by explaining that target accepts 'all' or an exact mesh object and that output goes to a unique job subfolder. However, it does not define how an exact object should be referenced or what input_path formats are accepted.
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 uses a specific verb ('Enable'), identifies the affected resource ('mesh objects'), and scopes the action to either 'all' or one exact object. This clearly distinguishes it from sibling tools like asset.export or material.list, and the output-file sentence does not obscure the primary 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 is given for when to choose this tool over alternatives such as asset.apply_material, asset.transform, or asset.export. The only implied context is the operation itself, with no when-not or exclusions.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds valuable transparency by explicitly stating 'Creates new GLB, BLEND, and FBX files without changing the input.' This clarifies the non-destructive write behavior and output format. However, it does not mention details like whether existing output files are overwritten or any permission requirements, though annotations lower the bar for this dimension.
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 sentences, no wasted words. The primary action is front-loaded, followed by essential constraints and output behavior. Every sentence contributes value, and the length is appropriate for the tool's scope.
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 6 parameters and no schema descriptions, this description covers the critical aspects: what it does, key input constraints, and output behavior. It lacks details on error handling or edge cases (e.g., what happens if target not found), but given the output schema exists and annotations are present, it is adequately complete for an agent to call it correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by clarifying that each supplied vector must be exactly three finite numbers (covering location, rotation_degrees, scale) and that target is 'all' or an exact object name. It also specifies rotation is in degrees. It does not describe input_path and output_directory, but these are self-explanatory from their names. The description adds meaningful semantics for the most ambiguous parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Set explicit location, Euler rotation in degrees, and/or scale on target objects.' This clearly distinguishes it from sibling tools like asset.apply_material or asset.add_modifier, which target different aspects. The mention of creating new GLB, BLEND, and FBX files further clarifies its purpose, though it doesn't explicitly name an alternative to compare against.
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 gives some usage context by explaining that 'target' can be 'all' or an exact object name, and that it creates new files without modifying input. However, it does not explicitly state when to choose this tool over alternatives, nor does it mention any prerequisites or conditions that would make it the preferred choice. The guidance is implicit rather than explicit.
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 already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds the 'headless Blender' execution context and explicitly states the source file is never modified, which reinforces but also adds context beyond annotations. No contradiction with annotations, but the extra behavioral disclosure is modest.
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: the first states the primary action, the second enumerates what is returned. No filler, every sentence earns its place, and the most critical info (purpose) is front-loaded. An excellent example of efficient description.
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?
An output schema exists (not shown) so the return format is presumably covered. The description addresses the input format, the operation's purpose, and the safety guarantee (never modified). For a single-parameter inspection tool with annotations covering safety, this is complete. Minor missing details like error behavior or unsupported formats do not significantly hinder correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'input_path' string with no description (coverage 0%). The description compensates by specifying that the path must point to a GLB, FBX, or BLEND asset, which adds format constraint and clarifies the purpose of the parameter. This is meaningful beyond the schema's bare type declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Open') and resource ('GLB, FBX, or BLEND asset'), and clearly defines the return value: scene structure with object names/types, material slots, mesh counts, etc. This distinguishes it from the sibling mutation tools (apply_material, transform, add_modifier, export) which all perform actions; only this tool inspects the scene structure.
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 inspecting scene structure, but does not explicitly name alternatives or state when not to use it. Sibling tools are clearly mutation/export oriented, so an agent can infer when to use this tool, but no explicit routing is given. This is implied usage without exclusions.
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?
Annotations are all neutral/false, so the description carries the disclosure burden. It adds valuable behavior: 'Creates new GLB, BLEND, and FBX files without changing the input' (non-destructive) and 'Parameters for the other modifier are rejected' plus per-type range constraints. This exceeds what annotations convey, though it omits any mention of auth or failure modes.
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 compact sentences with zero filler. The primary purpose and restriction are front-loaded, and modifier-specific parameter constraints occupy the second paragraph. Every sentence adds distinct 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?
With 7 parameters, 0% schema coverage, and no annotation safety info, the description covers the informative parts: parameter ranges, defaults, rejection semantics, and the non-destructive output behavior. The implicit parameters are low-risk, and the output schema exists, so nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains width (0..1000), segments (1..16, defaults 0.1/3), and ratio (0.01..1, default 0.5), and clarifies that cross-type parameters are rejected — real meaning beyond the bare schema. input_path, output_directory, and target are left implicit, but they are self-evident string parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Add), constrained resource (only Bevel or Decimate modifier), and precise scope (exact target mesh objects). The 'only' qualifier plus the enumerated modifier types sharply distinguishes it from the sibling set, none of which concern modifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it — when a Bevel/Decimate modifier must be added to a mesh — but never names alternatives or gives explicit when-not-to-use guidance. Differentiation from siblings is implicit by domain (no sibling is modifier-related) rather than stated.
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?
Annotations indicate non-read-only and non-destructive, but the description adds valuable context: outputs and logs are isolated in an operation-ID subfolder, and the input is never overwritten. This goes beyond the annotations and clarifies side effects, though it does not mention any required permissions or disk write specifics.
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 with no redundant phrasing. The primary action is front-loaded, and the additional behavioral detail is presented efficiently. Every word contributes meaning.
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 presence of an output schema (which explains return values) and the relatively simple 3-parameter interface, the description covers the essential behavior: what it does, output isolation, and non-overwriting. It could mention validation constraints (e.g., path existence) but these are not critical for invocation. Overall, it is sufficiently complete for an agent to call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It clarifies that 'formats' must be a non-empty unique list of GLB, BLEND, and/or FBX, but does not elaborate on input_path or output_directory semantics beyond their names. The names are self-explanatory, so the description provides moderate value but does not fully compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and the resource 'complete asset', specifying the target formats (GLB, BLEND, FBX). It distinguishes from siblings like scene.inspect or material.list, which have different purposes. The action 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the export tool among siblings, but it does not explicitly state when to use it versus alternatives or provide exclusions. However, the context is clear enough that an agent can infer it is for exporting assets, not for inspection or modification. A small gap: no mention of scenarios where export might not be appropriate.
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-control-mcp MCP server](https://glama.ai/mcp/servers/parkspark/blender-control-mcp/badges/card.svg)](https://glama.ai/mcp/servers/parkspark/blender-control-mcp)

Score Badge

Copy to your README.md:

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

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