Skip to main content
Glama

get_scene_info

Fetch structured text facts about a Blender scene—objects, placement, hierarchy, mesh and rig health, and settings—to inspect or audit it before making edits.

Instructions

Facts about the scene as text: what's there, where, how big, and how healthy meshes and rigs
are. No image; to see the scene, use look.

One header line (object counts, active, selection, mode), then one line per object with the
fields you ask for. Top-level objects by default; root="Name" lists that object's hierarchy,
query="chair" lists every object whose name contains the text. For anything else about an
object, read it with execute_blender_code.

Parameters:
- fields: What to show per object (default: location, size, children, hidden).
  placement: location (world), size (world bounding box), ground (on ground, floating or
    below by), rotation (degrees), scale, parent
  contents: children (count), hidden, details (faces, bones or light power), materials,
    modifiers, animation
  health: topology (quads, tris, ngons, non-manifold and boundary edges, loose verts,
    poles), weights (vertices no deform bone moves, deform bones with no vertex group)
  settings: adds a line with the file, engine, frame range, resolution, camera, HDRI and
    unit scale
- query: Name filter across all objects.
- root: Object whose hierarchy to list.
- limit: Maximum object lines (default 20).
- user_prompt: The user's own words describing what they want, quoted verbatim.

Input Schema

NameRequiredDescriptionDefault
rootNo
limitNo
queryNo
fieldsNo
user_promptNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.2.4

TDQS

A4.8/5.0
Behavior4/5

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

Without annotations, the description carries the behavioral burden and does well: it explains the output structure (header line plus one line per object), default fields, filtering behavior, and the absence of images. It does not explicitly state read-only safety or side-effect profile, but the 'get facts' framing and output format make the read behavior clear.

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

Conciseness5/5

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

Front-loaded with purpose and alternative, then structured into output format, scoping behavior, and parameter semantics. The length is justified by the 0% schema coverage and the need to enumerate field options.

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 five parameters, no annotations, and an output schema, the description is complete enough to invoke correctly. It covers output shape, defaults, filtering, field selection, and when to use siblings instead.

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%, so the description must compensate, and it does: every parameter is explained, including field categories (placement, contents, health, settings) with specific meanings and defaults, plus root/query/limit behavior and user_prompt's purpose.

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: returns facts about the scene as text, including objects, placement, and mesh/rig health. It also explicitly distinguishes itself from the visual sibling by saying 'No image; to see the scene, use look.'

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?

Explicitly directs the agent to use 'look' for visual inspection and 'execute_blender_code' for anything else about an object. It also defines default scope (top-level objects) and how root/query alter that scope.

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