bambu-printer-mcp

Overview Schema Source Related Servers Discussions Admin

blender_mcp_edit_model

Destructive

Import, edit, and export a local STL through Blender MCP with decimation, remeshing, or boolean unions, then verify output while preserving existing scene objects.

Instructions

Import, edit, and export a local STL through standard Blender MCP with verified output and existing scene objects preserved. Requires a shared local filesystem and Blender Object Mode. Also supports a separately configured legacy executable bridge.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "stl_path": "<stl_path>",
      "operations": "<operations>"
    },
    "name": "blender_mcp_edit_model"
  }
}

Input Schema

Name	Required	Description
`execute`	No	Apply edits and export (true) or validate and return the prepared request without connecting (false, default).
`stl_path`	Yes	Path to the local STL file
`operations`	Yes	Ordered operations: decimate:<ratio greater than 0 and at most 1>, remesh:<positive voxel size in STL units>, boolean_union:<STL path>. Legacy custom bridges define their own operations.
`timeout_ms`	No	Total Blender request deadline in milliseconds; defaults to BLENDER_MCP_TIMEOUT_MS or 120000.
`output_path`	No	Required for standard MCP previews and execution: new local STL output path whose parent exists. Existing files are never overwritten. Optional for legacy-only bridge configuration.
`user_prompt`	No	The user's own words describing the edit, passed unchanged to Blender MCP.
`bridge_command`	No	Legacy custom bridge executable override, not a standard MCP command. Per-call overrides require MCP_ALLOW_EXECUTABLE_ARG=1.

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv1.1.14Sep 29, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

changedInput schema / properties / bridge_command / description

Previous value: -"Override command for invoking Blender MCP bridge"New value: +"Legacy custom bridge executable override, not a standard MCP command. Per-call overrides require MCP_ALLOW_EXECUTABLE_ARG=1."

changedInput schema / properties / execute / description

Previous value: -"Execute bridge command (true) or return payload only (false)"New value: +"Apply edits and export (true) or validate and return the prepared request without connecting (false, default)."

changedInput schema / properties / operations / description

Previous value: -"Ordered edit operations for Blender (e.g. remesh, boolean, decimate)"New value: +"Ordered operations: decimate:<ratio greater than 0 and at most 1>, remesh:<positive voxel size in STL units>, boolean_union:<STL path>. Legacy custom bridges define their own operations."

addedInput schema / properties / operations / maxItems
```
Added value: +64
```
addedInput schema / properties / operations / minItems
```
Added value: +1
```

addedInput schema / properties / output_path

Added value: +{
+  "description": "Required for standard MCP previews and execution: new local STL output path whose parent exists. Existing files are never overwritten. Optional for legacy-only bridge configuration.",
+  "type": "string"
+}

addedInput schema / properties / timeout_ms

Added value: +{
+  "description": "Total Blender request deadline in milliseconds; defaults to BLENDER_MCP_TIMEOUT_MS or 120000.",
+  "maximum": 300000,
+  "minimum": 100,
+  "type": "integer"
+}

addedInput schema / properties / user_prompt

Added value: +{
+  "description": "The user's own words describing the edit, passed unchanged to Blender MCP.",
+  "type": "string"
+}

First observedv1.1.1May 17, 2026

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already flag destructive=true, idempotent=false, openWorld=true, so the safety profile is covered. The description adds genuine value beyond that: it promises 'verified output' and that existing scene objects are preserved, which bounds the destructive risk, and it discloses the filesystem/Object Mode preconditions plus an alternate legacy executable path. It does not discuss timeouts, partial failure, or operation-ordering semantics, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and scope, then prerequisites. No filler or marketing language. Slightly dense in the second sentence where two distinct concerns (filesystem/Object Mode requirement and legacy bridge variant) are compressed without separation.

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 7-parameter destructive tool with no output schema, the description covers the essentials: what it does, environment prerequisites, preservation guarantee, and the existence of a legacy mode. The parameter-level contract is fully carried by the rich schema. It lacks any statement of failure behavior or what 'verified output' concretely means, a minor but real gap.

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 100% and every parameter including the operations DSL, execute flag, timeout, and output_path non-overwrite rule is documented inline in the schema. The description adds no parameter-level detail beyond restating the environment requirements, so the baseline of 3 applies.

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 names a specific compound verb chain (import, edit, export) and a specific resource (local STL via Blender MCP), which is far more informative than a generic 'call Blender' sibling. It does not explicitly contrast itself with blender_mcp_call or the transform-only siblings (scale_stl, rotate_stl, merge_vertices), so the boundary is inferred rather than stated.

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?

Prerequisites are stated ('shared local filesystem', 'Blender Object Mode', 'separately configured legacy executable bridge'), which tells the agent when the tool is viable. However there is no guidance on when to prefer this over blender_mcp_call for arbitrary scripting, or over scale_stl/rotate_stl/center_model for simple transforms, and no explicit when-not-to-use condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server