Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

set_parameters

Batch-write multiple parameters to a Houdini node in a specified order, with options to override expressions and run callbacks, returning per-parameter results.

Instructions

Batch-set multiple parameters on a node, in the order given.

Inside a DOP network a write does not reset frames already simulated: simulation_cache names the network to pass to reset_simulation.

Parameters that held an expression and therefore ignored the literal are listed in expressions_kept, with a top-level warning: a batch whose errors is empty can still contain a write that did not take. Values that landed on ANOTHER node, because the parameter is a bare ch() reference Houdini writes through, are in written_through. Each entry in set carries the same keys as set_parameter's reply. Pass override_expression=True to clear those expressions and links instead.

Locked parameters are in errors with locked: true and listed in locked_parms; the error names the menu whose callback sets the lock. With run_callbacks=True each parameter's callback runs after its write, so {"res_mode": "manual", "resolutiony": 1080} unlocks and then writes; a callback that raised is listed in callbacks_not_run.

Args: node_path: Node path. params: Mapping of parameter names to values, written in this order. A value written {"expr": "...", "language": "hscript" | "python"} is set as an expression, as in build_network, also as one component of a list ("t": [{"expr": "$F"}, 0, 0]). A ramp takes the whole ramp at once: {"keys": [0, 1], "values": [[1, 0, 0], [0, 0, 1]], "basis": "linear"} (one basis or one per key; a float ramp takes numbers), the shape get_parameter reads it in. A ramp's new_value is what it holds once the whole call is through, so a key added by count and then set reads as set. override_expression: Remove expressions standing in the way. run_callbacks: Run each parameter's callback script after its write, as the UI does.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYes
node_pathYes
run_callbacksNo
override_expressionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.24.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / run_callbacks
      Added value: +{
+  "default": false,
+  "title": "Run Callbacks",
+  "type": "boolean"
+}
  2. Changed1 schema field changedv2.21.0
    • addedInput schema / properties / override_expression
      Added value: +{
+  "default": false,
+  "title": "Override Expression",
+  "type": "boolean"
+}
  3. First observedv0.1.0

TDQS

A4.5/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 unusually well: it discloses the expressions_kept/warning trap (empty errors yet a write that didn't land), written_through for ch() references, locked:true errors naming the lock menu, callbacks_not_run, and the DOP simulation_cache/reset_simulation interaction.

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?

Purpose is front-loaded, followed by dense but earning behavioral nuances, with Args clearly delimited at the end. It is long and some references ("as in build_network", "the shape get_parameter reads it in") lean on cross-tool knowledge, but nearly every sentence carries necessary information for this complex 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?

With no output schema, the description explains the reply fields (expressions_kept, warning, written_through, errors, locked_parms, callbacks_not_run) and the nested params structure fully. Nothing essential for correct invocation appears missing for a 4-parameter tool with nested objects.

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 the Args section does: it documents node_path, the expression dict format ({"expr", "language"}), ramp dict structure (keys/values/basis), and the semantics of override_expression and run_callbacks. This adds substantial meaning 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?

Opens with a specific verb+resource+scope: 'Batch-set multiple parameters on a node, in the order given.' This clearly distinguishes it from the singular sibling set_parameter and from set_expression via the batch/ordered framing.

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?

It provides context (DOP writes not resetting simulated frames, override_expression to clear expressions/links, run_callbacks semantics) but never explicitly states when to prefer this over set_parameter, set_expression, or set_keyframes. Usage is hinted at through behavioral notes rather than routing guidance.

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