Skip to main content
Glama

maya_session

Manage an Autodesk Maya session: query scene state, run Python commands, render stills, and create shelf buttons.

Instructions

Manage Maya session, query scene state, and run utility commands.

Available actions:

• ping — Check connection to Maya, return version/scene/renderer. No params needed. • launch — Open Maya and wait for Command Port to respond. No params needed. • new_scene — Create a new empty scene. Refuses if the current scene has unsaved changes; pass {"confirm": true} to discard them. • save_scene — Save the current scene. No params needed. • list_scene — List objects in the scene. Optional params: {"object_type": "mesh", "name_filter": "sphere"} • scene_snapshot — Full scene state: file, modified flag, frame range, object counts by type, renderer, plugins, resolution. No params needed. • delete — Delete objects by name (wildcards supported). Required params: {"object_name": "sphere"} • execute_python — Run arbitrary Python in Maya. Assign result to 'result' variable. Required params: {"code": "import maya.cmds as cmds; ..."} Optional: {"timeout": 60} — seconds to wait for Maya (default 10, max 600); use for long operations, progress heartbeats stream every 10s while waiting. • shelf_button — Create a shelf button with Python code. Required params: {"label": "MyBtn", "command": "print('hello')"} Optional: {"tooltip": "...", "shelf_name": "Custom", "icon_label": "MCP"} • operation_history — Read recent durable-audit records (read-only; needs MAYA_AUDIT_LOG=1). Optional params: {"limit": 50, "tool": "maya_transform", "action": "execute_python", "status": "error"} • publish — Drive the native Toolkit publisher (tk-multi-publish2) inside an engine'd Maya (launched via 'tank'). params: {"mode": "preview"|"publish", "include": ["rig"], "exclude": ["render"], "comment": "...", "timeout": 600}. 'preview' returns the collected publish tree; 'publish' activates matching tasks then validate→publish→finalize. Dependencies are captured automatically by the publish plugins. • review_turntable — Deterministic Viewport-2.0 turntable playblast → .mov (RUNS IN MAYA, long op). Frames the model, orbits 360° over [start,end] at fps, 16:9 / square pixels / overscan, offScreen (never Arnold). Required params: {"out_path": "/path.mov"} (resolve via fpt tk_resolve_path template 'movie_asset_publish' with name= so the file is {Asset}{Task}v###.mov, e.g. DJ_Model_v001.mov — NOT 'turntable'). Optional: {"start":1,"end":100,"fps":25,"width":1920,"height":1080,"objects":[...],"focal":50,"timeout":600}. Returns the .mov plus the engine asset/task and a Version code {Asset}{Task} so the review Version is named after the task it was generated in. • render_still — Single-frame Arnold ray-traced still → a PNG at the exact out_path (long op). This is what "a still / render a still" means — a real Arnold render, NOT the VP2.0 grab of maya_viewport_capture (use that for a fast screenshot). Maya only EXPORTS the scene to a .ass; kick renders it out of process, so the review view transform actually applies (a Render View dump writes scene-linear and ignores colour management), no Render View window is opened, and the render can never hang Maya's main thread. Required params: {"out_path": "/review/….png"} (resolve via fpt tk_resolve_path so it lands in the review area with the pipeline name). Optional: {"camera":"persp","frame":42,"width":1920,"height":1080,"aa_samples":3,"view_transform":"…","timeout":600}. Returns JSON {rendered, size_kb, camera, frame, resolution, asset, task, version_code} or {error}. For a still "for review" the version_code ({Asset}{Task}) is what names the ShotGrid review Version — rendering alone does not put it in review; create the Version (fpt sg_create type=Version) + sg_upload the PNG afterwards.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.26.0
    • changedInput schema / $defs / SessionAction / enum
      Previous value: -[
      -  "ping",
      -  "launch",
      -  "new_scene",
      -  "save_scene",
      -  "list_scene",
      -  "scene_snapshot",
      -  "delete",
      -  "execute_python",
      -  "shelf_button",
      -  "operation_history",
      -  "publish",
      -  "review_turntable"
      -]New value: +[
      +  "ping",
      +  "launch",
      +  "new_scene",
      +  "save_scene",
      +  "list_scene",
      +  "scene_snapshot",
      +  "delete",
      +  "execute_python",
      +  "shelf_button",
      +  "operation_history",
      +  "publish",
      +  "review_turntable",
      +  "render_still"
      +]
  2. First observedv1.23.0

TDQS

A4.7/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so: it discloses long-running semantics, default and max timeouts (default 10, max 600), progress heartbeats every 10s, the out-of-process render design that prevents main-thread hangs, the fact that rendering alone does not create a review Version, and the write/destructive nature of new_scene (discards unsaved work only with confirm:true) and delete.

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?

The preamble is front-loaded and each action is a single scannable bullet with params inlined, which is the right structure for a 13-way dispatcher. It is long, and render_still in particular carries several explanatory clauses ('the review view transform actually applies…'), but almost all of the length is functional rather than padding.

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 13-action dispatch tool with a 0%-covered schema and an output schema present, this is complete: action semantics, param shapes, timeouts, prerequisites, and side effects are all given, and it even sketches return payloads where they affect follow-up work. Nothing an agent needs to invoke an action correctly 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 coverage is 0% — params is an untyped free-form object whose only guidance is '(see tool description)' — so the description must define every parameter, and it does: required vs optional params per action, wildcard support for delete/list_scene name filters, and the {label, command} shape for shelf_button. This fully compensates for the schema gap.

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 ('Manage Maya session, query scene state, run utility commands') and then enumerates all 13 dispatchable actions with their concrete effects. It explicitly distinguishes itself from siblings, e.g. render_still notes it is 'NOT the VP2.0 grab of maya_viewport_capture', so an agent can route correctly without reading 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 Guidelines4/5

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

Every action carries when-to-use context: new_scene 'Refuses if the current scene has unsaved changes', operation_history 'needs MAYA_AUDIT_LOG=1', render_still points to maya_viewport_capture for fast screenshots, and review_turntable/render_still both mandate resolving out_path via the fpt tk_resolve_path template. It stops short of stating when the overall dispatch tool should be preferred over single-purpose siblings like maya_transform.

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