Set display, render, bypass, template, or lock flags on a Houdini node to control its visibility, computation, and behavior in the scene.
Set flags on a node.
Args: ctx: MCP context. node_path: Node path. display: Display flag. render: Render flag. bypass: Bypass flag. template: Template flag. lock: Lock flag.
| Name | Required | Description | Default |
|---|---|---|---|
| lock | No | ||
| bypass | No | ||
| render | No | ||
| display | No | ||
| template | No | ||
| node_path | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. 'Set flags on a node' communicates mutation but not what happens when a flag is true, false, or null, whether flags persist, or what the operation returns. It does not contradict annotations, but it reveals almost nothing beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and the summary sentence is front-loaded, which is good. However, the Args section largely duplicates the schema's property titles, and the 'ctx: MCP context.' line carries no practical value for the agent. It is concise but not every line earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with six parameters, zero annotations, and no output schema, the description is incomplete. It does not explain the behavioral semantics of each flag, what null means, or the result of the call. An agent could call it correctly by guessing, but it cannot predict consequences or return behavior from this definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, but it merely repeats parameter names with one-word labels like 'Display flag' and 'Lock flag'. It adds no semantics about how the boolean/null values behave, whether flags are independent, or what 'bypass' vs 'template' mean in context. The 'ctx: MCP context' entry is also not present in the input schema and adds confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
'Set flags on a node' states a clear verb and resource, and the argument list names the five flags (display, render, bypass, template, lock), so an agent can tell this is the generic node-flag setter rather than something like set_cop_flags. It is not a pure tautology, though it leaves the meaning of each flag undefined. It doesn't explicitly differentiate from siblings, but the target and flag names are sufficiently specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives or whether null values mean 'leave unchanged'. There is no mention of preconditions, side effects, or cases where another flag-related tool should be used instead. All usage context is absent, so an agent must infer entirely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.