HoudiniMCP

Overview Schema Source Related Servers Discussions Admin

connect

Idempotent

Change how Houdini nodes feed each other: wire outputs to inputs, remove input wires, or reorder inputs in one undo group.

Instructions

Change how nodes feed each other.

Use it after node_edit made the nodes. A list of wires goes in one undo
group and one round trip.

Do not use it to wire a node that you make now: node_edit mode "create"
takes `input_path` and wires it in the same call. Do not use it to read the
wires: scene_overview mode "network" lists them.

mode:
    "connect"    — src_path feeds dst_path. dst_input_index chooses the
                   input, src_output_index the output. Both count from 0.
                   A wire into an input that has one replaces it.
    "disconnect" — path loses the wire on input_index.
    "reorder"    — path takes its inputs in the order input_indices.

For several wires, give `items`: for "connect", each item has src_path and
dst_path, and can have dst_input_index and src_output_index; for
"disconnect", each item has path, and can have input_index.

Returns JSON, one line for each wire, with the paths that Houdini used.
An input index that the node does not have is reported, not dropped.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	One of "connect", "disconnect", "reorder".	connect
`path`	No	disconnect and reorder: the node whose inputs change.
`items`	No	A list of wires for "connect" or "disconnect", each a dictionary with the keys of one wire, for example {"src_path": "/obj/geo1/grid1", "dst_path": "/obj/geo1/mountain1"}. An argument outside items is the default for each one.
`dst_path`	No	connect: the node whose input takes the wire.
`src_path`	No	connect: the node whose output feeds the wire.
`input_index`	No	disconnect: the input that loses its wire, from 0.
`input_indices`	No	reorder: the old input indices in their new order, for example [1, 0].
`dst_input_index`	No	connect: the input of dst_path, from 0.
`src_output_index`	No	connect: the output of src_path, from 0.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.7.6Oct 4, 2026

changedInput schema / properties / items / description

Previous value: -"A list of wires for \"connect\" or \"disconnect\", each a dictionary with the keys of one wire. An argument outside items is the default for each one."New value: +"A list of wires for \"connect\" or \"disconnect\", each a dictionary with the keys of one wire, for example {\"src_path\": \"/obj/geo1/grid1\", \"dst_path\": \"/obj/geo1/mountain1\"}. An argument outside items is the default for each one."

Changed42 schema fields changedv0.7.3Oct 4, 2026

removedInput schema / properties / dst_input_index / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / dst_input_index / description
```
Added value: +"connect: the input of dst_path, from 0."
```
removedInput schema / properties / dst_input_index / title
```
Removed value: -"Dst Input Index"
```
addedInput schema / properties / dst_input_index / type
```
Added value: +"integer"
```

removedInput schema / properties / dst_path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / dst_path / default
```
Removed value: -null
```

addedInput schema / properties / dst_path / description

Added value: +"connect: the node whose input takes the wire."

removedInput schema / properties / dst_path / title
```
Removed value: -"Dst Path"
```
addedInput schema / properties / dst_path / type
```
Added value: +"string"
```

removedInput schema / properties / input_index / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / input_index / description

Added value: +"disconnect: the input that loses its wire, from 0."

removedInput schema / properties / input_index / title
```
Removed value: -"Input Index"
```
addedInput schema / properties / input_index / type
```
Added value: +"integer"
```

removedInput schema / properties / input_indices / anyOf

Removed value: -[
-  {
-    "items": {
-      "type": "integer"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / input_indices / default
```
Removed value: -null
```

addedInput schema / properties / input_indices / description

Added value: +"reorder: the old input indices in their new order, for example [1, 0]."

addedInput schema / properties / input_indices / items
```
Added value: +{
+  "type": "integer"
+}
```
removedInput schema / properties / input_indices / title
```
Removed value: -"Input Indices"
```
addedInput schema / properties / input_indices / type
```
Added value: +"array"
```

changedInput schema / properties / items / anyOf

Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "items": {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "items": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "type": "array"
+  }
+]

removedInput schema / properties / items / default
```
Removed value: -null
```

addedInput schema / properties / items / description

Added value: +"A list of wires for \"connect\" or \"disconnect\", each a dictionary with the keys of one wire. An argument outside items is the default for each one."

removedInput schema / properties / items / title
```
Removed value: -"Items"
```

removedInput schema / properties / mode / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / mode / description

Added value: +"One of \"connect\", \"disconnect\", \"reorder\"."

removedInput schema / properties / mode / title
```
Removed value: -"Mode"
```
addedInput schema / properties / mode / type
```
Added value: +"string"
```

removedInput schema / properties / path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / path / default
```
Removed value: -null
```

addedInput schema / properties / path / description

Added value: +"disconnect and reorder: the node whose inputs change."

removedInput schema / properties / path / title
```
Removed value: -"Path"
```
addedInput schema / properties / path / type
```
Added value: +"string"
```

removedInput schema / properties / src_output_index / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / src_output_index / description
```
Added value: +"connect: the output of src_path, from 0."
```
removedInput schema / properties / src_output_index / title
```
Removed value: -"Src Output Index"
```
addedInput schema / properties / src_output_index / type
```
Added value: +"integer"
```

removedInput schema / properties / src_path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / src_path / default
```
Removed value: -null
```

addedInput schema / properties / src_path / description

Added value: +"connect: the node whose output feeds the wire."

removedInput schema / properties / src_path / title
```
Removed value: -"Src Path"
```
addedInput schema / properties / src_path / type
```
Added value: +"string"
```
removedInput schema / title
```
Removed value: -"toolArguments"
```

Addedv0.1.1Oct 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=true), and the description adds genuinely new behavioral context: a wire into an occupied input is replaced, a batch of wires lands in one undo group and one round trip, and invalid input indices are reported rather than silently dropped. That is exactly the kind of operational detail the annotations do not carry.

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?

Well front-loaded: purpose, then when-to-use/when-not-to-use, then mode semantics, then return shape. The mode block is somewhat verbose and partially duplicates schema descriptions, but every line is functional for a 9-parameter, 3-mode tool.

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

Completeness5/5

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

Covers all three modes, batching via `items`, index conventions, conflict resolution, and return format, and it even notes the outcome for invalid indices despite an output schema existing. An agent has everything needed to call it correctly on the first try.

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 100%, so 3 is the floor, and the description earns above it by explaining what the indices mean behaviorally (count from 0, dst_input_index picks the input, replacement on conflict) and which keys each `items` entry takes per mode. It still restates a fair amount of what the schema already says, keeping it out of 5 territory.

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 names the resource (node wiring) and the mode list makes the specific operations concrete: connect, disconnect, reorder, each with the exact semantics of src_path/dst_path/indices. An agent can distinguish this from node_edit and scene_overview without opening any schema.

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

Usage Guidelines5/5

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

Explicit sequencing ('Use it after node_edit made the nodes') plus two named exclusions with the alternative to use instead: node_edit mode "create" for wiring a node made in the same call, and scene_overview mode "network" for reading wires. Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server