Skip to main content
Glama

set_parameter

Set a Houdini parameter value, handling expression conflicts and write-throughs. Optionally run callbacks.

Instructions

Set a parameter value.

A parameter that holds an expression does NOT take a literal: Houdini writes the value into a slot the expression keeps overriding. The reply then carries expression_kept: true with the surviving expression and what you requested (plus same_as_evaluated when the expression happens to evaluate to that value right now) — read those before calling the write done. Pass override_expression=True to clear the expression first.

A parameter holding a BARE ch() reference is the opposite trap: Houdini writes THROUGH it into the parameter it reads, so the value lands on another node. The reply names that parameter in written_through.

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

A String parameter echoes raw_value (the unexpanded text, $JOB/...) next to the expanded new_value.

A list with {"expr": ...} components ("t": [{"expr": "$F"}, 0, 0]) and a whole ramp ({"keys", "values", "basis"}) go through set_parameters: this tool's value takes plain values only.

A LOCKED parameter (karmarendersettings resolutiony under res_mode autoheight) takes nothing at all; the error names the menu whose callback sets the lock. Houdini runs such callbacks only from the UI: set that menu with run_callbacks=True first, then the locked parameter.

Args: node_path: Node path. parm_name: Parameter name. value: New value (int, float, string, bool, or list). override_expression: Remove an expression standing in the way, instead of reporting that the write did not take. run_callbacks: Run the parameter's callback script after the write, as editing it in the UI does (callback_run in the reply, and callback_error when the callback raised).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYes
node_pathYes
parm_nameYes
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.6/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 thoroughly: it discloses the expression-slot trap and the reply fields that signal it (expression_kept, requested, same_as_evaluated), the ch() write-through hazard (written_through), the DOP simulation_cache requirement, raw_value vs new_value echoing, and the UI-only callback/lock behavior with run_callbacks. This is unusually rich behavioral disclosure for a mutation tool.

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 core action, then organized as discrete trap paragraphs (expression, ch() reference, DOP cache, string, list/ramp, locked) followed by Args. The length is largely earned by the tool's behavioral complexity, though a few sentences are tangled, e.g. the parenthetical about same_as_evaluated.

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, but the description explains the reply fields an agent must inspect (expression_kept, requested, same_as_evaluated, written_through, callback_run, callback_error) and the conditions that produce them. For a 5-parameter tool with zero schema descriptions and no annotations, nothing essential appears missing.

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 0% and none of the 5 properties have descriptions, so the description must compensate. It does so for the non-obvious parameters (override_expression, run_callbacks, and value's restriction to plain values), but node_path and parm_name are documented only as "Node path" and "Parameter name", adding little beyond their self-evident names.

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 ("Set a parameter value") and immediately draws the boundary against the sibling set_parameters (list-with-expression components and whole ramps). An agent can distinguish it from set_expression, set_parameters, and link_parameters from the text alone.

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?

Gives concrete when-not guidance (expressions, bare ch() references, locked parameters, list/ramp values) and names set_parameters as the alternative for structured values, plus the override_expression and run_callbacks escape hatches. It does not explicitly route the agent to set_expression or revert_parameter, so it stops short of fully explicit alternative coverage.

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