Skip to main content
Glama
Sign In
Houdini MCP

Houdini MCP

by beatreichenbach
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

generate_static_items

Creates static work items on a Houdini TOP node without cooking, letting you define items for downstream workflows without triggering evaluation.

Instructions

Generate static work items on a TOP node without cooking.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "node_path": "<node_path>"
    },
    "name": "generate_static_items"
  }
}

Input Schema

NameRequiredDescriptionDefault
node_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are supplied, so the description must carry the full behavioral burden. It discloses the non-obvious 'without cooking' behavior, but says nothing about mutation side effects, permissions, whether it alters the TOP node, or what is returned.

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?

A single efficient sentence with no filler, front-loading the action and scope. It is terse, but the terseness reflects a content gap rather than wasted wording.

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

Completeness2/5

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

For a tool with no annotations or output schema and an undocumented parameter, the description is too thin. It does not define 'static work items', explain node_path, or describe outcomes, leaving an agent unable to call it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single required node_path parameter is not mentioned explicitly. The phrase 'on a TOP node' hints that node_path identifies a TOP node, but no format, expected value, or role is given.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb 'Generate' and resource 'static work items' scoped to a TOP node, and the phrase 'without cooking' implicitly distinguishes it from cook_top_node. However, 'static work items' and 'TOP node' are domain jargon that the description does not unpack.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Only implies usage by contrasting with cooking; it never states when to choose this over cook_top_node or dirty_work_items, nor any prerequisites or exclusions.

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