Skip to main content
Glama

See the scene

scene_snapshot
Read-onlyIdempotent

See the scene as an inline image, instantly — no render job. Default: a revision's stored thumbnail (every mutation with generatePreview creates one; omit revisionId for the head; scene_apply previewMaxSidePx can opt into a larger 384..1024px thumbnail). Pass artifactId instead to view any PNG artifact inline (a render_create result or a render_turntable frame). Snapshot after every mutation to verify visually before an expensive render. opticsObjectIds selects existing cached optical measurements; it does not resample the image. For a fresh targeted query without rendering, use scene_apply with scene.analyze_optics. Snapshot policy 2026-11-03: scene_snapshot reads a stored image; it does not render or regenerate it. New thumbnails use the active camera and preserve its aspect ratio with a default maximum side of 384px; scene_apply previewMaxSidePx can request 384..1024px at the same sample setting, with more compute for larger images. Without a camera they frame scene bounds. Simple opaque untextured Principled models with no authored camera or lights and only a neutral default world use Workbench directly for shape and base colour; this cannot judge lighting, reflections or glass. Authored cameras, lights, worlds, image textures and linked shader inputs keep the existing lit preview: transmission uses 16-sample Cycles; other lit scenes use EEVEE. Unlit, unreadably dark or failed lit previews may fall back to Workbench for shape and base colour only. Historical thumbnails retain their original engine, size and framing. Read thumbnailEngine, thumbnailFraming, thumbnailSize and thumbnailOptics when available; unknown historical metadata is not inferred from this policy. Use render_create for fine detail, noise and final transmission quality. platform_status and docs_operations guide=true return this deployment's current snapshotPolicy on each call. Prefer those live results over a cached tool description. On connection and release changes, modern subscriptions/listen sends the requested, honored catalog notifications; legacy GET SSE sends tools, prompts and resources list_changed. Private/no-store responses and zero-TTL discovery metadata let compatible hosts rediscover automatically. The server cannot replace schemas retained by a host that ignores freshness signals or never subscribes. The policy version describes new generation behavior, not the age or settings of a stored image.

Input Schema

NameRequiredDescriptionDefault
projectIdNoRequired unless artifactId is given — the project whose scene to show
artifactIdNoView any PNG artifact instead; mutually exclusive with projectId
revisionIdNoWith projectId; defaults to the project head
opticsObjectIdsNoFilter cached per-object optics by ID; absent measurements remain unavailable. Does not change the image or compute new diagnostics.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds substantive context: it reads a stored thumbnail rather than rendering/regenerating, explains camera and framing defaults, engine fallbacks, and historical thumbnail metadata. This is meaningful behavior beyond what the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence is well front-loaded, but the description then expands into hundreds of words of snapshot policy, deployment metadata, subscription/listen behavior, and cache-freshness guidance that do not help an agent select or invoke this tool. Much of that content should live in platform_status or docs rather than in the tool description.

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?

Given the rich annotations, fully described schema, and absence of an output schema, the description covers the inline-image return, thumbnail-generation behavior, and metadata fields an agent may read. It is more than complete for this tool's complexity, even though the extra material hurts conciseness.

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 coverage is 100%, and the schema already documents projectId/artifactId exclusivity, revisionId defaulting to the head, and opticsObjectIds filtering cached measurements without resampling. The description reinforces those semantics but adds little syntax or meaning that is not already in the parameter descriptions.

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 opening sentence names a specific verb and resource ('See the scene as an inline image') and immediately distinguishes it from a render job. The description also names sibling alternatives (render_create, scene_apply, artifactId path), so an agent can tell what this tool is for without opening the 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?

It explicitly says to snapshot after every mutation to verify before an expensive render, and it routes fresh targeted queries to scene_apply with scene.analyze_optics and fine-detail work to render_create. The projectId-versus-artifactId path is also described, leaving little inference about when to use which mode.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources