mcp-for-maya

Overview Schema Source Related Servers Discussions Admin

Scene Render Preview

scene_render_preview

Read-onlyIdempotent

Render a single-frame, HUD-free playblast preview from a chosen Maya camera, restoring panel camera and time afterward. Use for clean camera previews in GUI Maya sessions.

Instructions

Single-frame playblast preview from a camera (clean, no HUD).

Boundary: Disambiguated from scene_viewport_snapshot (capture the panel as the artist sees it, HUD and selection highlights included) — scene_render_preview renders a chosen camera with the HUD suppressed.

GUI sessions only - headless sessions get a structured gui_session_required error.

Side-effect disclosures (read_only_hint is honest):

Switching the panel camera via the modelPanel camera flag is instantaneous, visible, and NOT undoable in Maya.
Net-zero side effect: the panel camera is restored on every path - success or failure - so terminal state equals entry.
The current time may visibly jump during capture; it is restored afterwards (playblast timeline quirk).
viewer=False: no playblast window pops up.
On failure the restore is still attempted; a failed restore is logged, never raised over the error result.
Only a killed Maya process can skip the restore.

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

Input Schema

Name	Required	Description	Default
`width`	No	Frame width in pixels (default 640). Rounded UP to a multiple of 4 server-side (playblast constraint); the actual size may also be clamped by the viewport - trust the returned metadata, not the request.
`camera`	No	Camera to look through (default: the panel's current camera).
`format`	No	"jpeg" (default) or "png". png recommended for wireframe/line-art review.	jpeg
`height`	No	Frame height (default 360). Same /4 rule.
`quality`	No	JPEG quality 1-100.
`max_size`	No	Longest-side cap for the returned image.
`session_key`	No	Maya session key.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Sep 30, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well past the annotations by disclosing the temporary camera switch (visible, not undoable in Maya), guaranteed restoration on success and failure, a visible time jump during capture, viewer=False suppressing the playblast window, and the only unrecoverable case (killed process). This is exactly the context an agent needs to reconcile 'read_only' with a panel mutation.

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-loads purpose, then boundary, then precondition, then numbered side-effect disclosures — a well-structured and skimmable shape. It runs slightly long, and items 5 and 6 are edge-case detail that could be compressed, but none of it is filler.

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?

Covers purpose, alternative, environment gating, and side effects thoroughly, and hints that returned metadata should be trusted for actual size. With no output schema, it could say more about what is actually returned (image payload vs. path, metadata fields), which is the one remaining gap for a 7-parameter tool.

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%, with per-parameter notes on the /4 rounding rule, size clamping, format choice, and jpeg quality, so the baseline is 3. The description adds no parameter-level guidance beyond implying camera selection and HUD suppression; all real semantics live in the schema.

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 verb+resource+output: a single-frame playblast preview rendered from a chosen camera with the HUD suppressed. It explicitly disambiguates from the closest sibling scene_viewport_snapshot by contrasting the two capture semantics, so an agent can select 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?

Names the alternative (scene_viewport_snapshot) and the condition that selects it (artist-visible panel with HUD/highlights), and adds a hard precondition: GUI sessions only, with a named structured error (gui_session_required) for headless. When-to-use, when-not-to-use, and failure mode are all covered.

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