Blender Bridge

Capture viewport screenshot

take_screenshot

Capture a screenshot through the local bridge and return it as tool output. Defaults to the current 3D viewport; pass source="camera" only when the user explicitly wants the active camera view.

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": "take_screenshot"
  }
}

Input Schema

Name	Required	Description
`width`	No	Requested screenshot width in pixels.
`format`	No	Image encoding for the captured screenshot: PNG or JPEG.
`height`	No	Requested screenshot height in pixels.
`source`	No	Use viewport for the current 3D view; camera requests the active scene camera view.
`quality`	No	Requested image-encoding quality, from 20 to 100.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 23, 2026

addedInput schema / properties / format / description

Added value: +"Image encoding for the captured screenshot: PNG or JPEG."

addedInput schema / properties / height / description

Added value: +"Requested screenshot height in pixels."

addedInput schema / properties / quality / description

Added value: +"Requested image-encoding quality, from 20 to 100."

addedInput schema / properties / source / description

Added value: +"Use viewport for the current 3D view; camera requests the active scene camera view."

addedInput schema / properties / width / description

Added value: +"Requested screenshot width in pixels."

First observedOct 23, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description adds that capture goes through the local bridge and that the image comes back as tool output — useful, since there is no output schema. It does not explain why the tool is not read-only (e.g., any state touched) or whether a file is written to disk.

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, zero filler, with the primary behavior and the default stated first and the one risky parameter caveat second. Every sentence earns its place.

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?

With no output schema, the description correctly notes that the screenshot is returned as tool output, which is the key thing an agent needs to know about the return value. It leaves minor gaps — whether an image file is also persisted, and the actual return shape — but is sufficient to call correctly.

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 width, height, format, quality, and source are all documented in the schema, establishing a baseline of 3. The description contributes only the source default (viewport), which the schema does not state; it says nothing about resolution, format, or quality trade-offs beyond the schema's own text.

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 states a specific verb and resource — capture a screenshot via the local bridge and return it as tool output. It clarifies the default target (current 3D viewport), but never distinguishes itself from the sibling take_screenshot_only, so an agent must infer the difference from names alone.

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?

It gives an explicit conditional rule for the source parameter — pass source="camera" only when the user explicitly wants the active camera view — which is exactly the kind of when/when-not guidance that prevents misuse. It stops short of naming alternatives such as take_screenshot_only or render_project_image, so there is no routing guidance between sibling capture tools.

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

All Blender Bridge tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?