HoudiniMCP

Overview Schema Source Related Servers Discussions Admin

playbar

Idempotent

Read or set the current Houdini session frame, scene range, and playback controls so time-dependent SOP geometry cooks at the frame you need.

Instructions

Read or set the time of the session.

Use it before you read geometry that changes over time: a SOP cooks at the
current frame, so the frame decides what you see.

Do not use it only to read another frame: geometry_inspect, node_inspect
and stage_inspect take `frames` and put the playbar back after. A frame
that you set here stays for the person and for every later call, and
"range" also changes what a flipbook covers, and a ROP whose range
follows $FSTART and $FEND.

mode:
    "get"      — the current frame and time.
    "frame"    — go to `frame`.
    "range"    — set the scene frame range to `start` and `end`.
    "playback" — set the playback range inside the scene range.
    "play"     — `action` is "play", "stop", "next", "previous", "start"
                 or "end". Playback needs a GUI.

Returns JSON.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`end`	No	range and playback: the last frame.
`mode`	No	One of "get", "frame", "range", "playback", "play".	get
`frame`	No	frame: the frame to go to.
`start`	No	range and playback: the first frame.
`action`	No	play: "play", "stop", "next", "previous", "start" or "end".

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed25 schema fields changedv0.7.3Oct 4, 2026
- removedInput schema / properties / action / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / action / default
```
Removed value: -null
```
- addedInput schema / properties / action / description
```
Added value: +"play: \"play\", \"stop\", \"next\", \"previous\", \"start\" or \"end\"."
```
- removedInput schema / properties / action / title
```
Removed value: -"Action"
```
- addedInput schema / properties / action / type
```
Added value: +"string"
```
- removedInput schema / properties / end / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / end / default
```
Removed value: -null
```
- addedInput schema / properties / end / description
```
Added value: +"range and playback: the last frame."
```
- removedInput schema / properties / end / title
```
Removed value: -"End"
```
- addedInput schema / properties / end / type
```
Added value: +"number"
```
- removedInput schema / properties / frame / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / frame / default
```
Removed value: -null
```
- addedInput schema / properties / frame / description
```
Added value: +"frame: the frame to go to."
```
- removedInput schema / properties / frame / title
```
Removed value: -"Frame"
```
- addedInput schema / properties / frame / type
```
Added value: +"number"
```
- removedInput schema / properties / mode / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / mode / description
```
Added value: +"One of \"get\", \"frame\", \"range\", \"playback\", \"play\"."
```
- removedInput schema / properties / mode / title
```
Removed value: -"Mode"
```
- addedInput schema / properties / mode / type
```
Added value: +"string"
```
- removedInput schema / properties / start / anyOf
```
Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / start / default
```
Removed value: -null
```
- addedInput schema / properties / start / description
```
Added value: +"range and playback: the first frame."
```
- removedInput schema / properties / start / title
```
Removed value: -"Start"
```
- addedInput schema / properties / start / type
```
Added value: +"number"
```
- removedInput schema / title
```
Removed value: -"toolArguments"
```
Addedv0.1.1Oct 4, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing persistent side effects: a frame set here 'stays for the person and for every later call', and 'range' also alters flipbook coverage and ROP ranges bound to $FSTART/$FEND. It also notes playback requires a GUI. It does not, however, clarify how 'get' versus mutation modes interact with the declared idempotentHint for playback actions, leaving one small behavioral ambiguity.

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-loads the one-line purpose and the key timing constraint before the mode enumeration, and every sentence carries information. The mode list is necessarily long for a five-mode tool, though the parenthetical explanation of the 'play' action values duplicates the schema slightly.

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 multi-mode read/write session tool with an output schema available, the description covers timing, alternatives, per-mode semantics, persistence, and the GUI prerequisite. An agent has everything needed to choose a mode and call it correctly.

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 the baseline is 3, but the description adds real meaning: each mode value is glossed ('range' sets the scene frame range vs 'playback' sets the playback range inside the scene range), which the schema's bare enum list does not convey. The start/end/frame/action roles are also tied to specific modes.

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 precise verb pair and resource ('Read or set the time of the session') and immediately names the operational context (SOP cooks at the current frame). It is clearly distinguishable from siblings like node_edit or render, which do not touch the session playhead.

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?

Gives an explicit when-to-use ('before you read geometry that changes over time') and an explicit when-not-to-use, naming three alternatives (geometry_inspect, node_inspect, stage_inspect) and the parameter ('frames') that makes them preferable. Nothing is left to inference.

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

Deploy Server