Skip to main content
Glama

execute

Destructive

Run Python, HScript, or VEX code in a live Houdini session to access the full hou module, confirm APIs, evaluate expressions, check VEX, and read environment variables.

Instructions

Run code in Houdini, with the full hou module and no guard.

Use it for what no other tool covers, and to confirm an API in the live
session, for example `print(dir(hou.Node))`. The code runs with the rights
of the Houdini process: it can write files, delete nodes and quit Houdini.

Prefer a named tool when one exists. A write in code to a parameter that
holds an expression, that is disabled or hidden, or whose range clamps the
value changes nothing, and a write to a channel reference changes another
node. The answer lists each such write in `write_warnings`; read it. If you
write the same script twice, the named tool for it is missing: say so in
the feedback at the end of the session.

mode:
    "python"     — run `source` as Python. Returns stdout and stderr, and
                   keeps them when the script raises. Print what you want
                   to see: the value of the last line does not come back.
    "hscript"    — run `source` as an HScript command.
    "expression" — evaluate `source` as an expression. `language` is
                   "hscript" or "python".
    "vex_check"  — compile `source` as VEX and report the errors. Nothing
                   runs.
    "env"        — read the Houdini variable `name`, for example "HIP".
    "job"        — the state of the background job `job`: running, with
                   what it printed so far, or done, with its result.

Use `file` for a script that you run again with other values. Houdini
answers nothing while a script runs: for long work, such as a sweep, use
`background` with a large `timeout`. session action='interrupt' stops it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobNojob: the job id that background returned.
argsNofile: the values of sys.argv[1:].
fileNoA Python file to run instead of source, as from a shell: __file__ is its path, __name__ is "__main__", args are in sys.argv[1:]. The text travels once.
modeNoOne of "python", "hscript", "expression", "vex_check", "env", "job".python
nameNoenv: the Houdini variable to read, for example "HIP".
sourceNoThe code: Python, HScript, an expression or VEX, as mode says.
globalsNoNames that exist before the script runs, for example {"radius": 2.0}.
timeoutNoThe seconds the script may run. Past it, the script stops where it is, the answer says where, and what it changed stays.
languageNoexpression: "hscript" or "python".hscript
backgroundNopython: return at once with a job id and let the script run. Read it with mode job. Until it ends, other calls are refused.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.5
    • changedInput schema / properties / background / description
      Previous value: -"python: return at once with a job id and let the script run. Read it with mode job. Other calls wait until it ends."New value: +"python: return at once with a job id and let the script run. Read it with mode job. Until it ends, other calls are refused."
  2. Changed49 schema fields changedv0.7.3
    • removedInput schema / properties / args / anyOf
      Removed value: -[
      -  {
      -    "items": {
      -      "type": "string"
      -    },
      -    "type": "array"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / args / default
      Removed value: -null
    • addedInput schema / properties / args / description
      Added value: +"file: the values of sys.argv[1:]."
    • addedInput schema / properties / args / items
      Added value: +{
      +  "type": "string"
      +}
    • removedInput schema / properties / args / title
      Removed value: -"Args"
    • addedInput schema / properties / args / type
      Added value: +"array"
    • removedInput schema / properties / background / anyOf
      Removed value: -[
      -  {
      -    "type": "boolean"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / background / description
      Added value: +"python: return at once with a job id and let the script run. Read it with mode job. Other calls wait until it ends."
    • removedInput schema / properties / background / title
      Removed value: -"Background"
    • addedInput schema / properties / background / type
      Added value: +"boolean"
    • removedInput schema / properties / file / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / file / default
      Removed value: -null
    • addedInput schema / properties / file / description
      Added value: +"A Python file to run instead of source, as from a shell: __file__ is its path, __name__ is \"__main__\", args are in sys.argv[1:]. The text travels once."
    • removedInput schema / properties / file / title
      Removed value: -"File"
    • addedInput schema / properties / file / type
      Added value: +"string"
    • addedInput schema / properties / globals / additionalProperties
      Added value: +true
    • removedInput schema / properties / globals / anyOf
      Removed value: -[
      -  {
      -    "additionalProperties": true,
      -    "type": "object"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / globals / default
      Removed value: -null
    • addedInput schema / properties / globals / description
      Added value: +"Names that exist before the script runs, for example {\"radius\": 2.0}."
    • removedInput schema / properties / globals / title
      Removed value: -"Globals"
    • addedInput schema / properties / globals / type
      Added value: +"object"
    • removedInput schema / properties / job / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / job / default
      Removed value: -null
    • addedInput schema / properties / job / description
      Added value: +"job: the job id that background returned."
    • removedInput schema / properties / job / title
      Removed value: -"Job"
    • addedInput schema / properties / job / type
      Added value: +"string"
    • removedInput schema / properties / language / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / language / description
      Added value: +"expression: \"hscript\" or \"python\"."
    • removedInput schema / properties / language / title
      Removed value: -"Language"
    • addedInput schema / properties / language / type
      Added value: +"string"
    • removedInput schema / properties / mode / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / mode / description
      Added value: +"One of \"python\", \"hscript\", \"expression\", \"vex_check\", \"env\", \"job\"."
    • removedInput schema / properties / mode / title
      Removed value: -"Mode"
    • addedInput schema / properties / mode / type
      Added value: +"string"
    • removedInput schema / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / name / default
      Removed value: -null
    • addedInput schema / properties / name / description
      Added value: +"env: the Houdini variable to read, for example \"HIP\"."
    • removedInput schema / properties / name / title
      Removed value: -"Name"
    • addedInput schema / properties / name / type
      Added value: +"string"
    • removedInput schema / properties / source / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • removedInput schema / properties / source / default
      Removed value: -null
    • addedInput schema / properties / source / description
      Added value: +"The code: Python, HScript, an expression or VEX, as mode says."
    • removedInput schema / properties / source / title
      Removed value: -"Source"
    • addedInput schema / properties / source / type
      Added value: +"string"
    • removedInput schema / properties / timeout / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / timeout / description
      Added value: +"The seconds the script may run. Past it, the script stops where it is, the answer says where, and what it changed stays."
    • removedInput schema / properties / timeout / title
      Removed value: -"Timeout"
    • addedInput schema / properties / timeout / type
      Added value: +"number"
    • removedInput schema / title
      Removed value: -"toolArguments"
  3. Addedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructive/openWorld/non-idempotent, but the description adds concrete consequences beyond them: code runs with Houdini process rights and can write files, delete nodes and quit Houdini; writes to expression-driven, disabled/hidden, or range-clamped parameters silently do nothing; channel-reference writes affect other nodes; write_warnings must be read. It also discloses blocking behavior ('Houdini answers nothing while a script runs', 'other calls are refused' during a background job) and that a timed-out script's changes persist.

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 capability, the danger, and the routing rule before the mode enumeration. Dense and mostly waste-free, though the mode list makes it long enough that some readers may skim past the write_warnings and blocking notes.

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?

For a 10-parameter, output-schema-bearing power tool, it covers everything an agent needs: mode semantics, safety consequences, blocking/timeout behavior, and the write_warnings field it must read. Nothing essential is left to inference.

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 100%, so baseline is 3, but the description goes further than the schema by explaining what each `mode` actually does — stdout/stderr retention on python, that vex_check compiles without running, that env reads a Houdini variable, that job reports running/output/done state. It also clarifies file/args/globals interplay and timeout persistence, adding real meaning over the terse schema strings.

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 and resource ('Run code in Houdini') and immediately qualifies scope with 'with the full `hou` module and no guard', which distinguishes it from the named node/parameter tools. It also positions itself against siblings: 'Use it for what no other tool covers.'

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?

Explicit routing rules: 'Prefer a named tool when one exists', use `file` for re-run scripts, use `background` with a large `timeout` for long work, and session action='interrupt' to stop it. It even tells the agent what to do when it finds itself repeating a script (report the missing named tool in session feedback).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.