Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

connect_nodes

Wire two Houdini nodes together by specifying source and destination paths, plus optional output/input indices, input name, or subnet 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.18.0
    • addedInput schema / properties / indirect_input
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Indirect Input"
+}
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses parameter precedence ('input_name ... wins over input_index') and special subnet behavior, but does not state side effects such as whether existing connections are replaced or error/validation behavior. This is a meaningful gap for a mutation tool.

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?

Front-loaded with the core action, followed by a focused special-case note and a compact Args list. No filler; every line adds useful information.

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?

Covers all six parameters and the tricky subnet case despite no output schema and no annotations. Minor gap: it does not mention what the tool returns or how it handles invalid inputs, but the calling semantics are clear.

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%, but the Args section documents every parameter with meaningful semantics, including path roles, index meaning, the input_name precedence, and indirect_input constraint ('dest_path must live inside that subnet'). Fully compensates for the schema.

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?

States a specific verb and resource, 'Connect two nodes together,' and clarifies the special subnet indirect-input case, making it distinguishable from sibling tools like connect_nodes_batch and disconnect_node.

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?

Describes when to use the indirect_input form ('To feed a node INSIDE a subnet from one of the subnet's own input connectors...') and explains path semantics. Does not explicitly name alternatives or when-not conditions, so not a 5.

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