Skip to main content
Glama

scene_overview

Read-onlyIdempotent

List what the scene holds. Start here, before you touch a node.

Instructions

List what the scene holds. Start here, before you touch a node.

Modes: scene, network, children, search, node_types, errors, materials, lights, takes, caches, render_nodes, viewports, changes.

Use it to find a node path, to see the shape of a network, or to learn
which node types this Houdini has.

Do not use it to read one node in detail: node_inspect does that. Do not
use it to read geometry: geometry_inspect does that.

mode:
    "scene"        — file, frame range, counts, and the top of the tree.
    "network"      — the children of one network by name, with their
                     wires, flags and dots. Each input names the dot it
                     comes through, then the node behind the dot.
                     `pattern` and `node_type` keep some nodes;
                     compact=True gives only the wires.
    "children"     — the children of `path`. recursive=True walks down.
    "search"       — nodes whose name matches `pattern`, under `path`.
                     node_type filters by type name.
    "node_types"   — the node types this Houdini has, for one `category`
                     such as "Sop", "Object", "Lop", "Driver". `pattern`
                     keeps the names or labels that match.
    "errors"       — every node under `path` that has a cook error.
    "materials"    — the materials in `path` (default /mat) and the types.
    "lights"       — the lights on the USD stage of the LOP node `path`.
    "takes"        — the takes, and which take is current.
    "caches"       — file caches under `path` and their state on disk.
    "render_nodes" — the ROP nodes in /out.
    "viewports"    — the panes, and what the scene viewer shows.
    "changes"      — what the user changed in the network `path` since
                     your last call: nodes added, deleted, renamed or
                     moved, wires, flags and parameter values. Your own
                     changes are not listed. The first call starts to
                     watch the network; call it at the start of each
                     turn, before you change anything there.

Returns JSON. A path that does not exist comes back as an error, not as an
empty list.

Input Schema

NameRequiredDescriptionDefault
modeNoOne of "scene", "network", "children", "search", "node_types", "errors", "materials", "lights", "takes", "caches", "render_nodes", "viewports", "changes".scene
pathNoA node path such as "/obj" or "/obj/geo1": the network to list or to search.
compactNonetwork: return only the wires, one line each.
patternNosearch: the name to match, with * and ? as wildcards. network, node_types: keep the names that match; "|" separates alternatives, for example "*retarget*|*ik*".
categoryNonode_types: the context, for example "Sop", "Object", "Lop" or "Driver".
node_typeNosearch, network: keep the nodes of this type, for example "null".
recursiveNochildren: also list the children of the children.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.8.0
    • addedInput schema / properties / compact
      Added value: +{
      +  "default": false,
      +  "description": "network: return only the wires, one line each.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / mode / description
      Previous value: -"One of \"scene\", \"network\", \"children\", \"search\", \"node_types\", \"errors\", \"materials\", \"lights\", \"takes\", \"caches\", \"render_nodes\", \"viewports\"."New value: +"One of \"scene\", \"network\", \"children\", \"search\", \"node_types\", \"errors\", \"materials\", \"lights\", \"takes\", \"caches\", \"render_nodes\", \"viewports\", \"changes\"."
    • changedInput schema / properties / node_type / description
      Previous value: -"search: keep the nodes of this type, for example \"null\"."New value: +"search, network: keep the nodes of this type, for example \"null\"."
    • changedInput schema / properties / pattern / description
      Previous value: -"search: the name to match, with * and ? as wildcards."New value: +"search: the name to match, with * and ? as wildcards. network, node_types: keep the names that match; \"|\" separates alternatives, for example \"*retarget*|*ik*\"."
  2. Changed29 schema fields changedv0.7.3
    • removedInput schema / properties / category / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / category / default
      Removed value: -null
    • addedInput schema / properties / category / description
      Added value: +"node_types: the context, for example \"Sop\", \"Object\", \"Lop\" or \"Driver\"."
    • removedInput schema / properties / category / title
      Removed value: -"Category"
    • addedInput schema / properties / category / type
      Added value: +"string"
    • removedInput schema / properties / mode / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / mode / description
      Added value: +"One of \"scene\", \"network\", \"children\", \"search\", \"node_types\", \"errors\", \"materials\", \"lights\", \"takes\", \"caches\", \"render_nodes\", \"viewports\"."
    • removedInput schema / properties / mode / title
      Removed value: -"Mode"
    • addedInput schema / properties / mode / type
      Added value: +"string"
    • removedInput schema / properties / node_type / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / node_type / default
      Removed value: -null
    • addedInput schema / properties / node_type / description
      Added value: +"search: keep the nodes of this type, for example \"null\"."
    • removedInput schema / properties / node_type / title
      Removed value: -"Node Type"
    • addedInput schema / properties / node_type / type
      Added value: +"string"
    • removedInput schema / properties / path / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / path / default
      Removed value: -null
    • addedInput schema / properties / path / description
      Added value: +"A node path such as \"/obj\" or \"/obj/geo1\": the network to list or to search."
    • removedInput schema / properties / path / title
      Removed value: -"Path"
    • addedInput schema / properties / path / type
      Added value: +"string"
    • removedInput schema / properties / pattern / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / pattern / default
      Removed value: -null
    • addedInput schema / properties / pattern / description
      Added value: +"search: the name to match, with * and ? as wildcards."
    • removedInput schema / properties / pattern / title
      Removed value: -"Pattern"
    • addedInput schema / properties / pattern / type
      Added value: +"string"
    • removedInput schema / properties / recursive / anyOf
      Removed value: -[
      -  {
      -    "type": "boolean"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / recursive / description
      Added value: +"children: also list the children of the children."
    • removedInput schema / properties / recursive / title
      Removed value: -"Recursive"
    • addedInput schema / properties / recursive / type
      Added value: +"boolean"
    • removedInput schema / title
      Removed value: -"toolArguments"
  3. Addedv0.1.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, closed-world), and the description adds non-obvious behavior beyond them: a missing path returns an error rather than an empty list, `changes` excludes your own edits, and the first `changes` call begins watching. These are exactly the operational details an agent needs before relying on the output.

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 purpose and routing first, then the mode semantics, then return-value caveats — a logical order with no wasted sentences. The mode block is long but every entry earns its place given thirteen dispatch 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?

An output schema exists, so return format needn't be spelled out, yet the description still notes the JSON/error contract. All modes, the path-error behavior, and the stateful `changes` lifecycle are covered, leaving no gap an agent would need to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns above that by explaining what each mode actually returns and how pattern/node_type/compact/recursive modify behavior per mode. The per-parameter schema docs already carry syntax, so the gain is semantic rather than syntactic.

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 ("List what the scene holds") and front-loads its role as the entry-point discovery tool. It explicitly distinguishes itself from node_inspect and geometry_inspect, so an agent can route correctly without opening any 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?

Provides explicit when-to-use ("Start here, before you touch a node", find a node path, see a network, learn node types) and explicit when-not-to-use, naming both alternatives (node_inspect, geometry_inspect). The modes list doubles as a selection guide for 13 distinct query shapes.

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