mcp-for-maya

Overview Schema Source Related Servers Discussions Admin

Scene Nodes

scene_nodes

Read-onlyIdempotent

Enumerate all Maya scene nodes, including non-DAG types like materials, shading engines, and tool nodes, with pagination and filters. Complements spatial snapshots by listing what they miss.

Instructions

Bounded enumeration of scene nodes - including non-DAG nodes.

Boundary: scene_snapshot is the low-resolution spatial overview you call once per workflow; scene_nodes is the name-discovery complement for the API layer - it lists nodes a spatial view never shows (materials, shadingEngines, tool nodes) and pages honestly: has_more/next_cursor tell you when the list was cut.

Input Schema

TableJSON Schema

Name	Required	Description
`type`	No	Node type filter. With inherited=True (default) derived types match too (ls type= semantics, e.g. type="light" matches spotLight/directionalLight); inherited=False pins the exact type.
`limit`	No	Page size (default 50, hard-capped at 100).
`cursor`	No	Opaque page token from a previous call's next_cursor; valid while the scene is unchanged.
`pattern`	No	Maya glob pattern on names (e.g. "GEO_*").
`dag_only`	No	Only DAG nodes (transforms/shapes); False includes dependency nodes such as materials and utility nodes.
`inherited`	No	See type.
`session_key`	No	Maya session key (auto-selected if one session).
`include_type_counts`	No	Also return per-type counts over the full match set (not just the page).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.4.1Sep 30, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's added value is the disclosure that results are bounded and that has_more/next_cursor signal a truncated list. That is genuine pagination behavior an agent needs. It does not, however, discuss session/auth prerequisites despite exposing session_key.

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?

Two compact sentences, with the scope claim front-loaded ahead of the sibling contrast. The phrasing 'pages honestly' is a touch colloquial and the boundary paragraph carries mild abstraction, but nothing is wasted or buried.

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 an output schema present, return values need no explanation, and all eight parameters are schema-documented. The description supplies the sibling boundary and pagination caveat, leaving it nearly complete for a read-only enumeration 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%, so all eight parameters (type inheritance, limit cap, cursor validity, glob pattern, dag_only) are already documented in the schema. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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 and resource ('bounded enumeration of scene nodes') and immediately narrows scope with 'including non-DAG nodes'. It explicitly distinguishes itself from scene_snapshot, so an agent can route between the two 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 sibling alternative (scene_snapshot) and states the condition that selects each: snapshot is the once-per-workflow spatial overview, scene_nodes is the name-discovery complement that surfaces nodes a spatial view never shows. The routing decision is explicit rather than inferred.

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