HoudiniMCP

Overview Schema Source Related Servers Discussions Admin

docs

Read-onlyIdempotent

Search and read the official Houdini documentation for your installed build, covering nodes, parameters, VEX functions and HOM calls, so API names match your version.

Instructions

Read the official Houdini documentation.

This is the authority on every node, parameter, VEX function and HOM call.
Read the page before you use an API that you have not confirmed in this
session: names and enum members change between Houdini releases, and a
wrong one often fails without a message.

Do not answer from memory, and do not read sidefx.com yourself.

The pages come from the Houdini install on this machine, so they match the
build exactly. The first search on a build indexes it once, which takes a
few seconds; the index stays on disk. A page read never waits for it.

Give exactly one of `query` (search), `page` (read a page from a hit) or
`node` (the page of a node type). A node path is the only input that needs
Houdini.

Returns markdown for a page, JSON for a search.

Input Schema

TableJSON Schema

Name	Required	Description
`node`	No	A node path in the scene, for example "/obj/geo1/attribwrangle1", or a node type name, for example "mountain". Returns the page of that node type.
`page`	No	A page path from a hit, for example "nodes/sop/copytopoints". A loose name or a sidefx.com address also works.
`part`	No	A long page comes in parts of about 20,000 characters: 2, 3 and so on read the next ones.
`build`	No	The Houdini build to read, for example "21.0.829". Default: the build of the attached session, then $HFS, then the newest build on this machine.
`limit`	No	query: how many hits come back.
`query`	No	Words to search, for example "copy to points". Returns the hits with their page paths.
`section`	No	Read only the part of a page under one heading, for example "Quick renders and flipbooks". A long page lists its headings.
`category`	No	query: keep the search inside one folder, for example "nodes/sop", "vex/functions" or "hom/hou". node with a type name: the context, for example "sop" or "lop".

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed39 schema fields changedv0.7.3Oct 4, 2026

removedInput schema / properties / build / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / build / default
```
Removed value: -null
```

addedInput schema / properties / build / description

Added value: +"The Houdini build to read, for example \"21.0.829\". Default: the build of the attached session, then $HFS, then the newest build on this machine."

removedInput schema / properties / build / title
```
Removed value: -"Build"
```
addedInput schema / properties / build / type
```
Added value: +"string"
```

removedInput schema / properties / category / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / category / default
```
Removed value: -null
```

addedInput schema / properties / category / description

Added value: +"query: keep the search inside one folder, for example \"nodes/sop\", \"vex/functions\" or \"hom/hou\". node with a type name: the context, for example \"sop\" or \"lop\"."

removedInput schema / properties / category / title
```
Removed value: -"Category"
```
addedInput schema / properties / category / type
```
Added value: +"string"
```

removedInput schema / properties / limit / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / limit / description
```
Added value: +"query: how many hits come back."
```
removedInput schema / properties / limit / title
```
Removed value: -"Limit"
```
addedInput schema / properties / limit / type
```
Added value: +"integer"
```

removedInput schema / properties / node / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / node / default
```
Removed value: -null
```

addedInput schema / properties / node / description

Added value: +"A node path in the scene, for example \"/obj/geo1/attribwrangle1\", or a node type name, for example \"mountain\". Returns the page of that node type."

removedInput schema / properties / node / title
```
Removed value: -"Node"
```
addedInput schema / properties / node / type
```
Added value: +"string"
```

removedInput schema / properties / page / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / page / default
```
Removed value: -null
```

addedInput schema / properties / page / description

Added value: +"A page path from a hit, for example \"nodes/sop/copytopoints\". A loose name or a sidefx.com address also works."

removedInput schema / properties / page / title
```
Removed value: -"Page"
```
addedInput schema / properties / page / type
```
Added value: +"string"
```

removedInput schema / properties / part / anyOf

Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / part / description

Added value: +"A long page comes in parts of about 20,000 characters: 2, 3 and so on read the next ones."

removedInput schema / properties / part / title
```
Removed value: -"Part"
```
addedInput schema / properties / part / type
```
Added value: +"integer"
```

removedInput schema / properties / query / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / query / default
```
Removed value: -null
```

addedInput schema / properties / query / description

Added value: +"Words to search, for example \"copy to points\". Returns the hits with their page paths."

removedInput schema / properties / query / title
```
Removed value: -"Query"
```
addedInput schema / properties / query / type
```
Added value: +"string"
```

removedInput schema / properties / section / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / section / default
```
Removed value: -null
```

addedInput schema / properties / section / description

Added value: +"Read only the part of a page under one heading, for example \"Quick renders and flipbooks\". A long page lists its headings."

removedInput schema / properties / section / title
```
Removed value: -"Section"
```
addedInput schema / properties / section / type
```
Added value: +"string"
```
removedInput schema / title
```
Removed value: -"toolArguments"
```

Addedv0.1.1Oct 4, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only cover the safe-read profile (readOnly/idempotent/not open-world). The description adds real behavior: pages come from the local install so they match the build, the first search indexes a build in a few seconds and persists to disk, and page reads never wait on the index. It also discloses return formats (markdown for a page, JSON for a search).

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?

Front-loaded with the purpose, then usage rules, then operational behavior, then the parameter contract. Short paragraphs, no filler; each sentence carries a distinct instruction or disclosure.

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 an output schema present, return values need only light mention, and the description still summarizes them. Combined with the mode contract, build defaulting behavior (session build, then $HFS, then newest), and the indexing caveat, an agent has everything needed to 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 meaning beyond the schema by stating the mutually exclusive mode contract ('give exactly one of query, page, or node') which the schema does not express as a oneOf, and by noting that 'node' is the only input needing a live Houdini session. It does not add detail for part/build/section/limit/category.

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 ('Read the official Houdini documentation') and immediately scopes it ('the authority on every node, parameter, VEX function and HOM call'). This clearly separates it from all siblings, which manipulate or inspect the live scene rather than read reference docs.

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 when-to-use ('read the page before you use an API that you have not confirmed in this session'), why it matters (names and enum members change between releases and wrong ones fail silently), and explicit exclusions ('do not answer from memory, do not read sidefx.com yourself'). 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