Skip to main content
Glama
oc4n

MCP for Blender

by oc4n
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

look

Capture the Blender scene or selected objects as an image from viewport, camera, angles, or animation frames with adjustable shading and resolution for visual verification.

Instructions

See the scene as one image. For counts, sizes and positions, use get_scene_info.

Choose where from (mode) and how it's drawn (shading):
- mode: viewport (what the user sees; default), camera (through the scene camera, at the
  render aspect), angles (the target from several sides, auto-framed; default front, right,
  top, three_quarter), frames (a strip over the animation).
- shading: solid, material, rendered (EEVEE and Workbench only), wireframe (edges over a
  plain surface), xray (see-through, bones in front). Default: the viewport's.
- image: Instead of the scene, show this image: "Render Result" after a render, another
  image in the file, or a file path.

Parameters:
- target: Object names to frame (children included). Default: every visible object.
- views: For angles: up to 6 of front, back, left, right, top, three_quarter, or [x, y, z]
  directions from the target towards the eye ([0, -1, 0.2] is front, slightly above).
- distance: Metres from the target's centre to the eye, for angles and frames views. Default:
  far enough to fit it; closer for detail or to stand inside a room.
- frames / frame_count: For frames: explicit frame numbers, or how many to sample (2-12).
- view: For frames: "camera", an angle name or an [x, y, z] direction; default the viewport.
- max_size: Longest side in pixels (default 768). Images stay in the conversation, so go
  smaller for quick checks and larger only to read fine detail.
- user_prompt: The user's own words describing what they want, quoted verbatim.

Every setting changed to take the picture is restored afterwards.

Input Schema

NameRequiredDescriptionDefault
modeNo
viewNo
imageNo
viewsNo
framesNo
targetNo
shadingNo
distanceNo
max_sizeNo
frame_countNo
user_promptNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.4

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it discloses the side effect ('Every setting changed to take the picture is restored afterwards'), engine limits ('EEVEE and Workbench only'), and output handling ('Images stay in the conversation'). It stops short of stating failure modes or whether long renders block, which keeps it from 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?

Front-loaded with the one-line purpose and the sibling redirect, then a clearly grouped mode/shading/image block followed by a parameter list. Dense but nearly every line earns its place for 11 parameters; the mode bullet's nested parentheses are the only readability tax.

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 an 11-parameter tool with no output schema, the description covers invocation thoroughly and hints at the return ('as one image', images staying in conversation). It does not state what comes back for angles/frames (multiple images in a strip) or error behavior, leaving a small gap in an otherwise complete definition.

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 coverage is 0%, so the description must supply all 11 parameter meanings — and it does, with defaults and worked examples ([0, -1, 0.2] is front slightly above; 2-12 frames; 768px default). Format details like [x, y, z] direction vectors and accepted angle names are given where the schema gives none.

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 concrete verb+resource: 'See the scene as one image', immediately followed by the sibling it is NOT ('For counts, sizes and positions, use get_scene_info'). An agent can distinguish it from get_scene_info without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent away to get_scene_info for numeric queries, and gives per-value usage context for mode (viewport = what the user sees, angles = multi-side inspection, frames = animation strip) and shading. Defaults for each are stated, so selection requires no inference.

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