Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_parm_references

Identify which parameters reference a given Houdini node parameter and what that parameter reads, so you can safely rename or debug dependencies.

Instructions

Who references a parameter, and what it references — in one call.

incoming: for each parameter of the node (or just parm_name), the parameters elsewhere whose expressions read it — what breaks if this control is renamed. outgoing: what this node's expressions and backtick strings read, resolved to parameter paths (pure ch() links and richer expressions alike; unresolved names a written target that no longer exists). node_dependents / node_references give the node-level view for this node only; include_node_level in the reply says whether they were included.

Args: node_path: Node to inspect. parm_name: One parameter instead of all of them. direction: "both", "incoming" or "outgoing". limit: Cap on reported entries. include_node_level: Include node_dependents / node_references. Default: on for a whole-node query, off when parm_name names one parameter; on an asset with hundreds of children those lists run to about 100 KB and answer a question about the node, not the parameter.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
directionNoboth
node_pathYes
parm_nameNo
include_node_levelNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.24.1
    • addedInput schema / additionalProperties
      Added value: +false
  2. Changed1 schema field changedv2.21.0
    • addedInput schema / properties / include_node_level
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Include Node Level"
+}
  3. Addedv2.18.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations the description carries the load, and it does: it discloses the reply fields (incoming, outgoing, unresolved, node_dependents/node_references), explains that 'unresolved' names a written target that no longer exists, and warns that node-level lists run ~100 KB on large assets. It never states the operation is non-destructive/read-only, which is the main unstated trait.

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 a one-line summary, then cleanly partitioned into reply-field prose and an Args block. The 100 KB justification for include_node_level's default is slightly long but is load-bearing; overall tight and well ordered.

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?

With no annotations and no output schema, the description is expected to cover behavior and returns, and it names the reply keys and their meaning. It omits the concrete shape/types of entries and any pagination semantics for limit, leaving minor gaps for a 5-param query tool.

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: it enumerates the direction values ('both'/'incoming'/'outgoing') that the schema omits, explains parm_name as scoping to one parameter, defines limit as a cap on entries, and spells out the default-on/default-off logic for include_node_level. This adds substantial meaning beyond an empty schema.

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: 'Who references a parameter, and what it references', then breaks it into incoming (who reads this parm) and outgoing (what this node reads). The scope is unambiguous, but it never names or differentiates from adjacent siblings like get_expression, link_parameters, or get_parameter.

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?

Provides clear operative context — incoming answers 'what breaks if this control is renamed' and outgoing lists what expressions/backtick strings read. That effectively tells an agent when each direction applies, though it stops short of naming alternative tools or explicit exclusions.

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