Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_usd_attribute

Read a USD attribute value from a prim in Houdini. Get full values or slice large arrays with offset and limit for efficient access.

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.

Args: node_path: LOP node path. prim_path: USD prim path. attr_name: Attribute name. time: Time code (frame number). full: Return the whole array as value. offset: First element of the window for a long array. limit: Window size for a long array.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNo
timeNo
limitNo
offsetNo
attr_nameYes
node_pathYes
prim_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations present, the description carries the behavioral transparency burden. It discloses important non-obvious behavior: arrays over 16 elements return a summary plus a slice with has_more, and full=True returns every element. It does not mention auth, side effects, or error behavior, but for a read operation it provides substantial behavioral context.

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?

The description is well-structured: a one-line purpose, a focused paragraph on array behavior, then a compact Args list. Each section earns its place and the most important usage behavior is front-loaded before parameter details.

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 tool with no output schema and no annotations, the description covers parameter semantics and the tricky long-array behavior thoroughly. It leaves minor gaps around the exact return value for short/non-array attributes and error handling, but an agent can still call the tool correctly from this text alone.

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 description coverage is 0%, so the description must compensate. It provides an Args block with meaningful one-line semantics for all seven parameters, including the role of offset, limit, and full in array access, plus time as a frame number. This exceeds what the bare input schema offers.

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 line, "Read a USD attribute value from a prim," uses a specific verb and resource and clearly identifies the operation. It is easily distinguished from siblings such as set_usd_attribute and other USD query tools. The additional array behavior confirms this is a read-only attribute access tool.

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

Usage Guidelines4/5

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

The description gives clear guidance for using the tool with large arrays: it explains summary vs slice responses, offset walking, limit, and full=True. It does not explicitly name alternatives or state when-not-to-use, but the read operation and array-walking context are clear enough to guide correct invocation.

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