Skip to main content
Glama

revert_parameter

Restore a Houdini parameter to its default value by providing the node path and parameter name, eliminating manual reset and ensuring clean state.

Instructions

Revert a parameter to its default value.

Args: node_path: Node path. parm_name: Parameter name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
node_pathYes
parm_nameYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the parameter is reverted to default, but does not mention side effects (e.g., removing expressions or overrides), permissions required, whether the operation is reversible, or what happens if the parameter is already at default. This is an incomplete disclosure for a mutation 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?

The description is extremely short and front-loaded. It contains only a clear action sentence and a minimal parameter list, with no unnecessary words. It earns its place by being immediately scannable.

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?

Although the tool is simple (two params, no output schema), the description lacks essential context such as the expected format for node_path, the meaning of 'revert' in Houdini (e.g., resetting to built-in default vs. clearing expressions), and any error conditions. An agent without prior Houdini knowledge would likely be uncertain how to correctly invoke it.

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?

The schema has zero description coverage (only titles), so the description must compensate for the missing parameter information. The Args section merely repeats the parameter names ('Node path.', 'Parameter name.') without adding formats, examples, or constraints. This adds little beyond the schema titles and fails to tell the agent what a valid node_path or parm_name looks like.

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?

The description clearly states a specific verb ('revert') and the resource ('parameter to its default value'), which is distinct from sibling tools like set_parameter or get_parameter. It unambiguously tells the agent what action is performed.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It implies usage solely through the action word 'revert', but does not explicitly mention, for example, that it should be used instead of set_parameter when a reset to default is desired.

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