Skip to main content
Glama

get_usd_prim

Get a USD prim's attributes, relationships, and children at a given frame, with long arrays summarized to keep responses small.

Instructions

Get detailed info about a USD prim.

Array attributes longer than 16 elements (points, faceVertexIndices, primvars:st, ...) come back as a summary: size, element_type, the first 8 as head, and min/max for numeric data. That is what a mesh question needs; the full arrays of a building ran to 6.6 million characters. Pass full=True for every element, or read one array in windows with get_usd_attribute(offset=, limit=).

Values are read at time, or at the current frame when it is not given -- what a render of that frame sees; the reply names both as time and time_source. An attribute with time samples carries time_samples: its value differs at other frames. Relationships (a RenderSettings' camera) are listed with their targets. For the same attributes across many prims, get_usd_attributes reads them in one call.

Args: node_path: LOP node path. prim_path: USD prim path. full: Return array attributes in full instead of summarised. traverse_instance_proxies: List the children that live on an instanceable prim's prototype. Without it such a prim answers children: [] and is flagged is_instanceable with a hidden_descendants count, so the empty list is not read as "nothing inside". time: Time code (frame) to read at; default the current frame. attr_patterns: Glob patterns on attribute and relationship names (e.g. ["resolution", "karma:global:*"]); default all.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNo
timeNo
node_pathYes
prim_pathYes
attr_patternsNo
traverse_instance_proxiesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.24.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / attr_patterns
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Attr Patterns"
      +}
    • addedInput schema / properties / time
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Time"
      +}
  2. Changed1 schema field changedv2.21.0
    • addedInput schema / properties / traverse_instance_proxies
      Added value: +{
      +  "default": false,
      +  "title": "Traverse Instance Proxies",
      +  "type": "boolean"
      +}
  3. Changed1 schema field changedv2.18.0
    • addedInput schema / properties / full
      Added value: +{
      +  "default": false,
      +  "title": "Full",
      +  "type": "boolean"
      +}
  4. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so richly: it discloses array summarization (size, element_type, head of 8, min/max) and why, the time default and how the reply names time_source, that time-sampled attributes carry time_samples, that relationships come back with targets, and that instanceable prims return children: [] with hidden_descendants so emptiness isn't misread.

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?

Front-loaded with purpose, then behavior, alternatives, and an Args block; most sentences earn their place. The '6.6 million characters' anecdote is slightly indulgent but functions as rationale for summarization, so it mostly justifies itself.

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 6-parameter, no-annotation, no-output-schema tool, the description covers behavior, return shape conventions, defaults, and alternatives thoroughly. Nothing an agent needs to call it correctly appears to be missing.

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 0%, so the description must compensate, and it documents all six args with real semantic content for the non-obvious ones (full, time, attr_patterns globs, traverse_instance_proxies). The node_path and prim_path entries are thin restatements, but the remaining args are explained both in the body and the Args block.

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?

It states a specific verb and resource ('Get detailed info about a USD prim') and implicitly distinguishes itself from siblings by routing to get_usd_attribute for single arrays and get_usd_attributes for many prims. An agent can tell what this does and when a sibling is preferable 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?

Names two concrete alternatives with the conditions that select them: get_usd_attribute(offset=, limit=) for reading one array in windows, and get_usd_attributes for the same attributes across many prims. That is explicit routing guidance rather than implied usage.

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

Deploy Server

Other Tools