Skip to main content
Glama
healkeiser

fxhoudinimcp

by healkeiser
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_help_page

Fetch one page of Houdini's shipped documentation by path.

Instructions

Fetch one page of Houdini's shipped documentation by path.

Read the real reference instead of writing from memory — especially the VEX function pages (vex/functions/...) before any justified wrangle, and expression pages (expressions/...) before channel expressions.

A page comes 20,000 characters at a time. A longer one is truncated and names next_offset and its sections with their offsets: read on with offset, or jump to a section by its title.

Args: path: As returned by search_help — e.g. "nodes/sop/scatter", "vex/functions/noise", "expressions/ch". offset: Character offset to start from (a next_offset). section: Section title to start at, e.g. "Shape"; overrides offset.

Input Schema

NameRequiredDescriptionDefault
pathYes
offsetNo
sectionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.28.2
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
    • addedInput schema / properties / section
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Section"
+}
  2. Changed1 schema field changedv2.24.1
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well: it discloses the 20,000-character page size, that longer pages come back truncated with next_offset and a sections list, and how section overrides offset. It does not say what happens on an invalid path (error vs empty page), which is the main remaining gap for a read tool.

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 core action, followed by a short usage rationale, then pagination behavior, then an args block. Every sentence carries information an agent needs; nothing is redundant with the schema or restates the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-param read tool with no annotations and no output schema, the description covers pagination, continuation, and argument semantics well. Only minor gaps remain: error behavior for a bad path, and no statement that the operation is read-only.

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 description coverage is 0%, so the description must compensate, and it does: every parameter is documented with meaning and example values (path formats like 'nodes/sop/scatter', 'vex/functions/noise', 'expressions/ch'; offset is a character offset taken from next_offset; section is a title that overrides offset). This is meaningfully more than the bare types in the 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?

States a specific verb and resource ('Fetch one page of Houdini's shipped documentation by path') and implicitly differentiates itself from search_help, which is named as the source of the path argument. An agent can distinguish it from get_workflow_guide or search_help without opening any schema.

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 explicit when-to-use guidance: read the real reference instead of writing from memory, specifically VEX function pages before a wrangle and expression pages before channel expressions. It also names the prerequisite tool (search_help) for obtaining a valid path, so the workflow is unambiguous.

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