Skip to main content
Glama

set_hda_interface

Author an HDA's Type Properties interface in one call, defining parameters and optionally replacing existing definitions or previewing changes with dry run.

Instructions

Author an HDA's Type Properties interface in one call.

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>",
      "parameters": "<parameters>"
    },
    "name": "set_hda_interface"
  }
}

Input Schema

NameRequiredDescriptionDefault
dry_runNo
replaceNo
node_pathYes
parametersYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.2/5.0
Behavior2/5

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

No annotations are supplied, so the description carries the full burden, yet it discloses nothing about whether an existing interface is overwritten, what 'replace' or 'dry_run' actually do, or whether the operation is destructive. For a mutation tool this leaves the agent guessing about safety and side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded sentence with no filler, which is good, but the brevity comes at the cost of under-specification rather than economy. There is nothing extraneous, but also almost nothing useful.

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?

Given a mutation tool with no annotations, no output schema, four undocumented parameters, and a close sibling doing a similar job, the definition is far too thin to call correctly. An agent would have to inspect the schema and guess at the difference from 'edit_hda_interface'.

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

Parameters1/5

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

Schema description coverage is 0% across four parameters, and the description adds no meaning for any of them. In particular it never explains the free-form 'parameters' array structure or the semantics of 'replace' and 'dry_run', which are precisely the knobs an agent must understand before calling.

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

Purpose3/5

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

The verb 'Author' and resource 'HDA's Type Properties interface' identify the target, but 'author' is ambiguous between creating a fresh interface and rewriting an existing one. The sibling 'edit_hda_interface' is never mentioned, so an agent cannot tell from the description how these two differ.

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?

'in one call' faintly implies a bulk operation versus incremental edits, but no when-to-use, when-not-to-use, or alternative is stated. With 'edit_hda_interface' among the siblings, the absence of any routing guidance is a real gap.

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