Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

copy_node

Duplicate a Houdini node, optionally into another parent network, to preserve wiring and position while applying a new name or offset.

Instructions

Copy a node, optionally into a different parent network.

In the same network the copy lands one node width to the right of its original instead of on top of it; in another network it keeps the original's position. offset overrides both, and position in the reply says where the copy is. inputs lists the wires the copy kept ({index, from}, or {index, indirect_input} for a subnet's own input connector); inputs_not_copied the original's wires it could not keep, as in a copy into another network.

Args: ctx: MCP context. node_path: Source node path. dest_parent: Destination parent path. new_name: Name for the copy. offset: [dx, dy] from the original's position.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNo
new_nameNo
node_pathYes
dest_parentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.24.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / offset
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "number"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Offset"
+}
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses placement side effects (offset one node width right, position preserved across networks), how `offset` overrides defaults, and what happens to wires (which are kept vs. dropped as inputs_not_copied). It omits error conditions (e.g., invalid dest_parent, name collision handling), keeping it from a 5.

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?

The core behavior is front-loaded in the first sentence, followed by placement and wire semantics, then a standard Args block. Slightly redundant in places (offset/position explained both in prose and args), but every sentence is informative and there is no filler.

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?

No output schema exists, so the description helpfully documents the reply fields (position, inputs, inputs_not_copied) that an agent would otherwise have to discover empirically. For a no-annotation mutation tool it is nearly complete, missing only failure modes and default naming behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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. The Args block gives each parameter a short gloss, but three of the four mostly restate the name (node_path = 'Source node path', dest_parent = 'Destination parent path'); only `offset` adds real semantics ([dx, dy] from the original's position). Partial compensation for the coverage gap.

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 (copy) and resource (node) with scope ('optionally into a different parent network'). An agent can distinguish it from create_node, move_node, and rename_node without inspecting 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 Guidelines3/5

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

The description explains the two operating contexts (same network vs another network) and how placement differs, which implies when each is relevant, but never names an alternative tool or states when to use this over create_node/duplicate. Usage is implied rather than prescribed.

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