Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_hda_interface

Define an HDA's type-level interface—tab folders, parameters, menus, and conditional visibility—in one call, with dry-run validation.

Instructions

Author an HDA's Type Properties interface in one call.

Use this for the asset's TYPE interface — tab folders, strict ranges, ordered menus, Hide/Disable When. create_spare_parameter is a different thing: it adds parameters to one node instance and never reaches the type.

Each entry of parameters is a dict: name, label, type (int|float|string|toggle|menu|folder), default, min, max, min_strict, max_strict, components, menu_items ([value, label] pairs or plain strings), folder_type (tabs|simple|collapsible|radio) + children for folders, hide_when / disable_when (Houdini conditionals), help.

Example — a Controls tab whose Bevel disappears for a single stud: [{"name": "controls", "label": "Controls", "type": "folder", "children": [ {"name": "stud_count", "type": "int", "default": 4, "min": 1, "max": 8, "min_strict": True, "max_strict": True}, {"name": "bevel", "type": "float", "default": 0.02, "min": 0.0, "max": 0.1, "hide_when": "{ stud_count == 1 }"}, {"name": "material", "type": "menu", "menu_items": [["plastic", "Plastic"], ["metal", "Metal"]]}]}]

It is edit_hda_interface with one insert per entry: names already in the interface are refused before anything is written, and the reply is read back off the definition — ops[].stored, renamed_by_houdini (a tab folder joins the existing tab set's naming series), not_found_after_write and instance_parms_missing.

Args: ctx: MCP context. node_path: An instance of the HDA whose definition is edited. parameters: Interface spec (see above). create_spare_parameters' spelling (parm_name, parm_type, default_value) is accepted too. replace: Start from an empty interface. Built-in parameters of the node type cannot be removed: Houdini puts them back (reinstated_by_houdini). dry_run: Validate and report the plan without writing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNo
replaceNo
node_pathYes
parametersYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.18.0

TDQS

A5/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. It discloses atomicity ('names already in the interface are refused before anything is written'), response read-back fields (ops[].stored, renamed_by_houdini, etc.), replace behavior including reinstated_by_houdini, and dry_run semantics. This is far beyond minimal behavioral disclosure.

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?

Though long, the description is densely organized into purpose, usage, parameter spec, example, behavior, and arguments. Every sentence adds value, and the core purpose is front-loaded before the details.

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?

Given the complex nested parameter structure, four parameters, zero schema coverage, and no output schema, the description covers every necessary aspect: parameter schema, behavior, edge cases (built-in params, naming series), and return fields. There are no obvious gaps for an agent to invoke it correctly.

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?

The input schema has zero description coverage. The description compensates by fully documenting the parameters dict: allowed types, field meanings, menu_items formats, folder children, Houdini conditionals, and an example. It also explains node_path, replace, and dry_run semantics, plus acceptance of create_spare_parameters spelling.

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 states a specific verb and resource: 'Author an HDA's Type Properties interface in one call.' It names a sibling tool, create_spare_parameter, and explains the distinction, and also references edit_hda_interface to position the tool exactly.

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?

It explicitly says 'Use this for the asset's TYPE interface' and contrasts it with create_spare_parameter, which 'adds parameters to one node instance and never reaches the type.' The relationship to edit_hda_interface is also stated, so an agent knows when to choose this tool over alternatives.

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