Skip to main content
Glama
Sign In
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_usd_attribute

Read a USD attribute value from a prim.

Instructions

Read a USD attribute value from a prim.

A long array (over 16 elements) answers with value as a summary (size, element_type, head, min/max) plus slice: the elements from offset, at most limit of them (default the first 64), with has_more. Walk a big array by raising offset; pass full=True to get every element in value at once.

A time-sampled attribute (a PointInstancer's positions, protoIndices) has nothing in its default slot: read with no time it answers null. With no time given, the current frame is read instead, and the reply carries time, time_source, time_samples and time_range, so value: null never stands unexplained next to is_authored: true. A time-sampled attribute also lists its sample_times (motion blur's subframes included): up to 64, past that sample_times_truncated and the 64 around the time read, from index sample_times_start. all_samples=True adds the value at each of them.

Args: node_path: LOP node path. prim_path: USD prim path. attr_name: Attribute name. time: Time code (frame number). Omitted on a time-sampled attribute, the current frame is used (the first sample outside the range). full: Return the whole array as value. offset: First element of the window for a long array. limit: Window size for a long array. all_samples: Also return samples: [{time, value}] for each listed sample time, a long array summarised. Refused with full=True.

Input Schema

NameRequiredDescriptionDefault
fullNo
timeNo
limitNo
offsetNo
attr_nameYes
node_pathYes
prim_pathYes
all_samplesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.27.0
    • addedInput schema / properties / all_samples
      Added value: +{
+  "default": false,
+  "title": "All Samples",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv2.24.1
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed3 schema fields changedv2.18.0
    • addedInput schema / properties / full
      Added value: +{
+  "default": false,
+  "title": "Full",
+  "type": "boolean"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 64,
+  "title": "Limit",
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
  4. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/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 substantively: long arrays return a summary plus a slice with has_more, time-sampled attributes return null in the default slot but carry time/time_source/time_samples/time_range, sample_times truncates at 64, and all_samples is refused with full=True. Error conditions (bad prim path, non-existent attribute) and any auth context are not covered, which keeps it out of the top band.

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 core purpose is front-loaded in the first sentence and each paragraph covers a distinct case (long arrays, time sampling, argument reference). The time-sampling paragraph is dense and the 'answers null ... current frame is read instead' phrasing takes a re-read to reconcile, and the Args block partially repeats the prose, so it is efficient but not tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a high-complexity, 8-parameter read tool with no output schema and no annotations, the description is nearly complete: it effectively documents the response shape (summary/slice/has_more, time metadata, samples) that the missing output schema would otherwise carry. It stops short of covering failure modes, and the absence of an output schema means edge cases around malformed paths or missing attributes remain unspecified.

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 description coverage is 0%, so the description must compensate, and it does: every one of the eight parameters is documented in the Args block, including non-obvious ones (time defaults to the current frame, limit defaults to the first 64, offset walks long arrays, all_samples conflicts with full). The three required path/name params get only terse labels ('LOP node path.', 'USD prim path.', 'Attribute name.'), which caps it just below 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read a USD attribute value from a prim'), so the operation is unambiguous. However, it never distinguishes itself from close siblings like get_usd_attributes, get_attribute_info, or get_attrib_values, leaving the agent to infer that this is the single-attribute value reader.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives operational guidance for the tool itself (walk a long array via offset/limit, use full=True for everything), which implies how to invoke it. It offers no when-to-use/when-not framing and never names a sibling alternative, so the routing decision between this and the plural/stat/info USD attribute tools is left implicit.

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