Sceneplane

Inspect scene

scene_inspect

Read-onlyIdempotent

Read a revision's scene from its stored structured summary — synchronous, no container. detail: summary | objects | materials | render | cameras | lights | stats | full. Use "cameras" to get camera ids for render_create cameraId, "lights" for the rig with energies, and "stats" for per-object vertex/face counts, UV presence and modifier stacks. Filter with objectIds, or with namePattern/excludeNamePattern — namePattern is how you turn the namePattern a copying operation reports (object.radial_array, object.array_along_curve) back into the full list of ids it created. limit/cursor page the requested entity type. In full mode each included collection uses the same offset/limit; nextCursor continues while any collection has more rows. Object filters affect objects, cameras and lights; materialIds independently filters materials. For exact node names, links and packed image bindings request includeNodeGraphs with detail=materials/full and one materialId or limit=1. Graphs are omitted by default; legacy or partial summaries explicitly report availability. All positions and sizes are metres (1 unit = 1000 mm).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum entries returned per requested scene section.
`cursor`	No	Row offset from nextCursor, e.g. "100". Keep the same revision, detail and filters when paging.
`detail`	No	Scene section to read; full combines all sections.	summary
`objectIds`	No	Filter by platform id ("obj_…"/"cam_…"/"lgt_…")
`projectId`	Yes	Stable project ID returned by project_create or projects_list.
`revisionId`	No	"HEAD" (default) uses the project's current head	HEAD
`materialIds`	No	Filter materials by stable mat_ IDs before pagination, independently of object filters.
`namePattern`	No	Filter by Blender object NAME with * wildcards, e.g. "Tick_*". This is how you resolve the namePattern a copying operation reports back into ids.
`includeNodeGraphs`	No	Read stored node graphs with detail=materials/full and exactly one materialId or limit=1. Includes counts and complete/truncated/unavailable status.
`excludeNamePattern`	No	Drop objects whose name matches, e.g. "Studio_*". Applied after namePattern.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 27, 2026

addedInput schema / properties / includeNodeGraphs

Added value: +{
+  "default": false,
+  "description": "Read stored node graphs with detail=materials/full and exactly one materialId or limit=1. Includes counts and complete/truncated/unavailable status.",
+  "type": "boolean"
+}

addedInput schema / properties / materialIds

Added value: +{
+  "description": "Filter materials by stable mat_ IDs before pagination, independently of object filters.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 16,
+  "minItems": 1,
+  "type": "array"
+}

First observedSep 24, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds significant behavioral context: 'synchronous, no container' (performance expectation), pagination semantics (nextCursor continues while any collection has more rows), filtering interactions (object filters affect objects, cameras, lights; materialIds independent), node graph omission by default, and explicit unit declaration (metres, 1 unit = 1000 mm). No contradiction with annotations; the description enriches them.

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 description is long but each sentence adds value. It starts with the core purpose and detail enumeration, then moves to filters, pagination, node graphs, and units. It is densely packed but logically ordered; no fluff. A slightly more scannable format (e.g., bullet lists) would improve, but the prose is efficient and front-loaded.

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 tool with 10 parameters and no output schema, the description is remarkably complete. It covers every parameter's usage, edge cases (legacy/partial summaries explicitly report availability), pagination continuation, filtering independence, node graph behavior, and units. There are no evident gaps an agent would need to resolve elsewhere. It is self-sufficient and deeply integrated with the surrounding tool ecosystem.

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 100%, so the schema already documents all parameters. The description goes far beyond: it explains that namePattern is the mechanism to resolve object.radial_array / object.array_along_curve names back to ids, clarifies that objectIds filter cameras/lights too, defines how limit/cursor page each entity type, and specifies that in full mode each collection uses the same offset/limit. It also explains the includeNodeGraphs requirement (one materialId or limit=1). This transforms raw parameter definitions into actionable knowledge.

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?

The description opens with a precise verb and resource: 'Read a revision's scene from its stored structured summary.' It immediately lists the eight detail modes, making the scope explicit. This clearly distinguishes it from sibling tools like scene_apply or scene_script, which imply mutation, while this one is read-only.

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?

Provides explicit usage instructions: which detail mode to use for camera ids, lights, stats; how to filter with objectIds vs namePattern; how to resolve namePattern from copying operations; pagination rules; and the exact conditions for includeNodeGraphs. It even links to render_create's cameraId, demonstrating cross-tool awareness. Though it doesn't name a specific alternative tool, the usage is so detailed that an agent knows exactly when to use this tool and how.

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

All Sceneplane 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?