bambu-printer-mcp

Overview Schema Source Related Servers Discussions Admin

blender_mcp_setup

DestructiveIdempotent

Checks or updates the MCP for Blender add-on required by the configured Blender bridge. With update enabled, it stages and verifies the package's add-on while keeping a backup.

Instructions

Check or update the MCP for Blender add-on that the configured Blender bridge (BLENDER_MCP_COMMAND uvx, BLENDER_MCP_ARGS naming mcp-for-blender or blender-mcp) needs. Without update: which add-on file Blender loads, its protocol and the protocol the package expects, whether Blender is listening and the running add-on's own handshake. Changes nothing. With update: true, stages the add-on with the package's own installer (mcp-for-blender install-addon) at the inspected version, checks it, keeps the old file as a backup next to it and renames the new one into place. Never starts, stops or edits Blender; a running Blender uses the new add-on once it is re-enabled or restarted. A custom bridge returns supported false.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "blender_mcp_setup"
  }
}

Input Schema

Name	Required	Description	Default
`update`	No	Replace the installed add-on with the package's own (default false: check only).

Output Schema

Name	Required	Description
`live`	No	The running add-on's get_addon_status (up_to_date, protocol_version, expected_protocol_version, blender_version); null when it has none or it couldn't be read. Only while listening.
`backup`	No	update: the previous add-on file, kept next to it.
`reason`	No
`target`	No	The add-on file Blender loads (for the running Blender's version, when it reports one).
`current`	No	The installed file carries the expected protocol. A running Blender may still have the old add-on loaded: see live.
`message`	No	What the person can do, in plain words, when the add-on can't be checked or updated here (with reason or target_problem). Clients show it as it is.
`package`	No	The package as BLENDER_MCP_ARGS names it.
`replaced`	No	update: the file was replaced. Blender runs the new add-on once it is re-enabled or Blender restarts.
`listening`	Yes	The add-on answers on BLENDER_HOST:BLENDER_PORT (default localhost:9876): Blender is running with it started.
`supported`	Yes	The configured bridge is the upstream MCP for Blender package run with uvx, so this tool can check and update its add-on.
`live_error`	No	Why the running add-on's handshake couldn't be read.
`target_problem`	No
`package_version`	No
`expected_protocol`	No	The add-on protocol the package needs.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.77Nov 7, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Goes well past the annotations: it discloses that the old add-on file is kept as a backup next to the new one, that the new file is renamed into place, that the installer used is the package's own (mcp-for-blender install-addon) at the inspected version, and that a running Blender only picks the change up after re-enable or restart. That is real side-effect detail consistent with destructiveHint=true, idempotentHint=true and openWorldHint=true, including what is and is not touched.

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

Conciseness4/5

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

Front-loaded with the verb and resource, then the no-update behavior, then the update behavior, then the hard limits. Every clause carries information, but the sentence structure is dense and comma-chained, which slows parsing of the important 'never edits Blender' constraint.

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, so return values need not be explained, and the annotations already carry the safety profile. The description supplies prerequisites, side effects, and failure mode (custom bridge), which is sufficient for a one-parameter setup tool; the main remaining gap is explicit routing versus blender_mcp_status and blender_mcp_call.

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 100% and the single boolean is fully described in the schema ('default false: check only'), so the baseline is 3. The description reinforces the two modes and spells out the consequences of update: true, but adds little about the parameter itself beyond what the schema already says.

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?

States a specific verb pair and resource: 'Check or update the MCP for Blender add-on' that the configured Blender bridge needs, and enumerates exactly what the check reports (add-on file path, protocol mismatch, listening state, handshake). It stops short of differentiating itself from the plainly related sibling blender_mcp_status, so an agent must infer that this is setup/repair rather than 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?

Usage is framed as two explicit modes: the default 'Changes nothing' check, versus 'With update: true, stages the add-on with the package's own installer'. It also states an exclusion ('Never starts, stops or edits Blender') and a boundary case ('A custom bridge returns supported false'). No sibling alternative such as blender_mcp_status is named, so the routing surface is a 'context, no exclusions' rather than a true 'when/when-not/alternatives' statement.

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

Deploy Server