Skip to main content
Glama

create_spare_parameter

Add a spare parameter to a node.

Instructions

Add a spare parameter to a node.

A menu needs its items: a menu without any is refused, not created with Houdini's "none" placeholder. The reply reads the menu back from the node (menu_items as [value, label] pairs, default_value as a value).

Args: node_path: Node path. parm_name: Internal parameter name. parm_type: "float", "int", "string", "toggle", or "menu". label: UI label. default_value: Default value. For a menu, the default item by value or index. min_val: Minimum value (float/int only). max_val: Maximum value (float/int only). menu_items: A menu's items, as set_hda_interface takes them: plain strings, or [value, label] pairs such as [["0", "Uniform"], ["1", "By Attribute"]].

Input Schema

NameRequiredDescriptionDefault
labelYes
max_valNo
min_valNo
node_pathYes
parm_nameYes
parm_typeYes
menu_itemsNo
default_valueNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.27.0
    • addedInput schema / properties / menu_items
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "anyOf": [
      +          {
      +            "type": "string"
      +          },
      +          {
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          }
      +        ]
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Menu Items"
      +}
  2. Changed1 schema field changedv2.24.1
    • addedInput schema / additionalProperties
      Added value: +false
  3. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations at all, the description carries the full burden, and it does disclose real behavior: an empty menu is refused rather than defaulted, and the reply echoes the parameter back from the node with `menu_items` as [value, label] pairs and `default_value` as a value. It still omits permission/auth requirements and undo/reversibility for this mutating operation.

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?

Front-loaded with the purpose, then behavior, then a per-argument list. Given eight parameters at zero schema coverage, the Args block earns its space; the phrasing is slightly verbose ('as set_hda_interface takes them') but not wasteful.

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 an unannotated, output-schema-less, eight-parameter mutation tool, the description covers purpose, the reply shape, and every argument — enough for correct invocation. The remaining gap is routing against the plural sibling `create_spare_parameters`.

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%, and the description compensates strongly: it enumerates the allowed `parm_type` values, restricts min_val/max_val to float/int, explains that `default_value` for a menu may be given by value or index, and gives a concrete [value, label] example for `menu_items`.

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 clear verb and resource: 'Add a spare parameter to a node.' The menu-specific rules make the scope concrete. However, it never distinguishes itself from the sibling `create_spare_parameters` (plural), which an agent could easily confuse with this singular variant.

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?

No explicit when-to-use or when-not-to-use guidance is given, and no alternative tool is named. The one constraint (a menu with no items is refused) is a validation rule for a parameter value, not usage guidance for selecting this tool over its plural sibling.

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