MCP for Blender

Overview Schema Source Related Servers Discussions Admin

generate_3d

Create and import a single textured 3D model into Blender from a text prompt or image, with job resuming for longer generations.

Instructions

Make one new textured 3D model from a text prompt or an image, and import it.

One object per call: not a whole scene, the ground, or parts to assemble. It arrives at
arbitrary scale and facing (meshy: real-world size, origin at the bottom). Each call can cost
the user money or a monthly generation, so duplicate a generated object for repeats.

Waits up to wait_seconds (at most 45), then imports. Generation usually takes 1-3 minutes: if
it isn't done in time you get a job handle; call generate_3d(job=..., name=...) again to keep
waiting. Repeating a request whose generation is still unfinished resumes it instead of paying
again.

Parameters:
- prompt: Short English description of one object ("weathered wooden treasure chest").
- image: Instead of a prompt: an absolute image file path or an http(s) URL. Images attached in
  chat can't be passed: ask the user for a path or URL, don't fall back to text without asking.
- name: Object name in the scene. Defaults to one made from the prompt.
- provider: auto (default), tripo, hunyuan3d, hyper3d or meshy. Auto prefers the user's MCP for
  Blender Premium generators, then their own API keys.
- quality: "standard" or "high" (Premium, not meshy). Omit for the user's default; "high" only
  when the user asks for more detail.
- bbox_condition: hyper3d only: [length, width, height] proportions.
- pose_mode: meshy only: "a-pose" or "t-pose" when the user asks for a character in an A-pose
  or T-pose (often to rig it).
- job: A handle from an earlier call, to resume waiting for it.
- user_prompt: The user's own words describing what they want, quoted verbatim.

Input Schema

Name	Required	Default
`job`	No
`name`	No
`image`	No
`prompt`	No
`quality`	No
`provider`	No	auto
`pose_mode`	No
`user_prompt`	No
`wait_seconds`	No
`bbox_condition`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.2.4Nov 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does it well: discloses monetary cost per call, the 45-second wait cap and the job-handle resume pattern, that repeats of an unfinished request resume instead of re-billing, and that geometry arrives at arbitrary scale/facing (real-world size with origin at the bottom for meshy). Minor wrinkle: schema default for wait_seconds is 50 while the text says 'at most 45'.

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 purpose and the one-object constraint, then cost, then waiting behavior, then a parameter glossary — a logical ordering with little filler. It is longer than the median definition, though nearly every clause conveys a non-obvious constraint an agent would otherwise get wrong.

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?

For a 10-parameter, high-cost generation tool with no annotations, the description covers cost, timing, resumption, provider routing, scale/orientation quirks, and per-parameter applicability. Return values are covered by the output schema, so nothing essential is missing.

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?

Schema description coverage is 0%, so the description must compensate and does: all ten parameters get meaning, including provider routing order ('Auto prefers the user's MCP for Blender Premium generators, then their own API keys'), per-provider applicability of bbox_condition and pose_mode, the default-behavior of name, and the explicit prohibition on passing chat-attached images.

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?

Opens with a specific verb+resource+scope: 'Make one new textured 3D model from a text prompt or an image, and import it.' It immediately bounds the output ('one object per call: not a whole scene, the ground, or parts to assemble'), which an agent can use to distinguish generation from import_asset or search_assets.

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?

Gives explicit when-to-use guidance for nearly every branch: image vs prompt, 'high' quality only when the user asks for more detail, preconditions for pose_mode/bbox_condition, and the cost-driven rule to duplicate rather than regenerate. It stops short of naming sibling tools (import_asset, search_assets) to say when *not* to generate.

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

Deploy Server