Skip to main content
Glama
DMontgomery40

MCP 3D Printer Server

by DMontgomery40
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

blender_mcp_edit_model

Import, edit, and export a local STL through Blender MCP while preserving existing scene objects. Validate edits or apply decimate, remesh, and boolean union operations.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
executeNoApply edits and export (true) or validate and return the prepared request without connecting (false, default).
stl_pathYesPath to the local STL file
operationsYesOrdered 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_msNoTotal Blender request deadline in milliseconds; defaults to BLENDER_MCP_TIMEOUT_MS or 120000.
output_pathNoNew local STL output path for standard MCP editing; defaults to a unique model-edited-<id>.stl beside the input. Its parent must exist and existing files are never overwritten. Reuse the preview's output_path when executing that plan.
user_promptNoThe user's own words describing the edit, passed unchanged to Blender MCP.
bridge_commandNoLegacy 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.

  1. First observedv1.2.9

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it delivers real behavioral claims: output is verified, existing scene objects are preserved, and a shared filesystem plus Object Mode are required. It stops short of stating reversibility or permission/auth implications, but the preservation and requirement disclosures are substantive beyond anything structured data provides.

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, no filler, front-loaded with the core action and pipeline before the requirements and the optional bridge. Every clause (verified output, scene preservation, prerequisites, legacy bridge) carries distinct information.

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 complex 7-parameter mutation tool with no output schema, the description covers purpose, prerequisites, side-effect profile, and the alternate bridge path. It does not clarify the difference between standard and bridge execution or what 'verified output' concretely means, which is a modest remaining 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%, so the schema already documents all seven parameters in detail (execute, output_path defaults, timeout, operations syntax). The description adds only the bridge concept, so the baseline 3 for schema-dominant definitions is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific three-part verb (import, edit, export) on a concrete resource (a local STL) through a named mechanism (standard Blender MCP). An agent can separate it from blender_mcp_export_stl (export only) and blender_mcp_call (generic) without opening any schema.

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) and the legacy-bridge path is flagged, which is useful context. However, it never states when to prefer this tool over siblings like blender_mcp_call or blender_mcp_export_stl, or when the bridge path applies, so usage remains implied rather than directed.

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

Deploy Server

Other Tools