Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

connect_nodes

Wire two Houdini nodes by connecting an upstream output to a downstream input, including subnet input connectors via source_path and indirect_input.

Instructions

Connect two nodes together.

To feed a node INSIDE a subnet from one of the subnet's own input connectors (a SubnetIndirectInput — not a node, it has no path), pass the subnet as source_path and the connector index as indirect_input.

Args: ctx: MCP context. source_path: Upstream node path; with indirect_input, the subnet whose input connector is the source. dest_path: Downstream node path. output_index: Source output index. input_index: Destination input index. input_name: Destination connector name or label (e.g. "base_color" on a VOP shader); wins over input_index. indirect_input: Index of the subnet input connector at source_path to wire from (dest_path must live inside that subnet).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dest_pathYes
input_nameNo
input_indexNo
source_pathYes
output_indexNo
indirect_inputNo

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.18.0
    • addedInput schema / properties / indirect_input
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Indirect Input"
+}
  3. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations the description carries full burden. It usefully discloses a non-obvious behavioral subtlety (SubnetIndirectInput is not a node, has no path, and dest_path must live inside the subnet), but omits what happens on invalid paths, whether connecting replaces an existing input connection, and permission/error behavior.

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-loads the purpose, then the special subnet case, then an Args block. Well organized and mostly free of filler, though the indirection paragraph is slightly verbose for the value it adds.

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 6-parameter connection tool with no annotations and no output schema, the definition covers the tricky subnet/connector semantics and every parameter. It is nearly complete, missing only failure/return behavior and coexistence with the batch tool.

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 largely does: all six parameters are explained, including precedence ('input_name ... wins over input_index'), defaults implied for indices, and a concrete example ('base_color' on a VOP shader). Only minor gaps remain, e.g. index base/range.

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+resource: 'Connect two nodes together'. The singular framing implicitly contrasts with the sibling connect_nodes_batch, but it never names that alternative or otherwise explicitly differentiates itself from related tools like disconnect_node or reorder_inputs.

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?

Provides a clear scenario for one mode: wiring a subnet's own input connector into a node inside that subnet (indirect_input). However it gives no guidance on when to prefer this tool over connect_nodes_batch, nor any preconditions such as valid paths or cycle avoidance.

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