Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

run_shelf_tool

Run a shelf tool and report the nodes it created.

Instructions

Run a shelf tool and report the nodes it created.

A tool that asks for objects takes selection, or the objects already selected, as in Houdini. A tool that asks for anything else is retried once as a Ctrl+click, Houdini's "place immediately" (ran_as_ctrl_click): the Crowds Simulate tool then builds its whole default crowd. A tool that still asks (the FLIP ocean layer, collide-with) is refused, since through the bridge it would block Houdini until someone clicks: read the recipe with get_shelf_tool_script and build the nodes with build_network.

Nodes the tool added inside networks that already existed (a FLIP tool into the current POP network) are listed in created_in_existing; current_dop_network says where DOP tools put theirs, before and after. A tool that creates a DOP network (model_popnet) does not make it the current one, so the next DOP tool would build into the previous network: pass that network as dop_network.

A tool whose script fails has what it built removed, and the error names it. A dialog tool refused for its question names, when there is one, a tool that builds the same branch without asking.

Args: tool_name: Internal tool name, from list_shelf_tools. kwargs: Overrides merged into the synthetic kwargs the script reads. parent_path: An extra network to watch for new nodes. /obj, /stage, /out, /mat and /img are always watched, because a shelf tool is free to build in more than one of them: largeOcean creates both a geo in /obj and a LOP in /stage. A SOP network given here is also where a SOP tool places its nodes (placed_in). selection: Object paths the tool takes as its object selection. The scene's selection is left as it was, whatever the tool selects. dop_network: DOP network to make current before the run (hou.setCurrentDopNet), where DOP tools build. It stays current afterwards, as when an artist picks it.

Input Schema

NameRequiredDescriptionDefault
kwargsNo
selectionNo
tool_nameYes
dop_networkNo
parent_pathNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.27.0
    • addedInput schema / properties / dop_network
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Dop Network"
+}
  2. Changed1 schema field changedv2.25.0
    • addedInput schema / properties / selection
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Selection"
+}
  3. Changed1 schema field changedv2.24.1
    • addedInput schema / additionalProperties
      Added value: +false
  4. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/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 so richly: it discloses the Ctrl+click retry and the ran_as_ctrl_click flag, refusal for dialog tools, that a failed script's nodes are removed and the error names the tool, that DOP tools leave their network current (side effect), and that SOP tools place into a supplied parent_path (placed_in). These are exactly the non-obvious behaviors an agent needs.

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 the one-line purpose before the behavioral paragraphs and Args block, and nearly every sentence carries operational detail. It is somewhat long and prose-dense relative to a 5-param tool, but little is filler.

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?

There is no output schema, so the description supplies the return-related facts (created_in_existing, current_dop_network, placed_in, ran_as_ctrl_click, error naming the failed tool). For a complex, side-effecting tool with no annotations and no output schema, it covers the behavior, side effects, and result reporting an agent needs.

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 documents all five parameters: tool_name's source (list_shelf_tools), kwargs as overrides merged into the script's synthetic kwargs, parent_path as an extra watched network with the always-watched list and its SOP 'placed_in' role, selection leaving the scene selection intact, and dop_network being made current and staying current. This is well beyond the bare 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?

The opening sentence gives a specific verb and resource ('Run a shelf tool and report the nodes it created'), and the body distinguishes it from siblings by naming list_shelf_tools (parameter source), get_shelf_tool_script and build_network (the fallback path when a tool is refused). An agent can tell what this does and how it differs from adjacent tools.

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?

It gives clear conditions: an asking tool is retried once as Ctrl+click, a tool that still asks is refused and the agent should instead read the recipe with get_shelf_tool_script and build with build_network. That is explicit when/when-not routing. It stops short of stating the high-level 'use this when you want a shelf tool's default result' selection rule versus building nodes manually, so not a full 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