Skip to main content
Glama

ha_set

Configure High Availability (HA) settings on a DrayTek router; changes require confirmation to apply.

Instructions

Configure HA (write — requires confirmation)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramYes
user_codeNo
acknowledgeNo
confirm_tokenNo
confirmation_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

C2.3/5.0
Behavior2/5

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

With no annotations, the description carries the full burden. It discloses that the operation is a write and requires confirmation, which is a useful behavioral signal, but it omits essential details such as what the confirmation process entails, potential side effects, reversibility, or required permissions. The mention of confirmation is a positive but insufficient start.

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

Conciseness2/5

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

The description is extremely short (six words plus parenthetical), which is not conciseness but under-specification. It front-loads the write nature but omits any structured guidance, making it too terse to be genuinely helpful. It could be concise while still including key operational details.

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

Completeness1/5

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

Given five parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what the confirmation token or confirmation_id are for, how the 'param' is structured, or what the response will be. The agent has almost no context to correctly invoke this tool, especially since it is a write operation requiring confirmation.

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%, and the description provides no explanation for any of the five parameters, including the required 'param'. It does not mention parameter purposes, formats, or relationships, leaving the agent completely reliant on the schema, which only gives types and constraints. This fails to compensate for the low schema coverage.

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?

The description clearly states the action ('Configure') and the resource ('HA'), distinguishing it as a write operation from read-only siblings like ha_show and ha_status. It avoids tautology and provides a specific verb and target, though it lacks detail on what specific HA settings are configured.

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 guidance is given on when to use this tool versus alternatives. The description does not mention conditions for using ha_set over ha_show or ha_status, nor does it explain the confirmation workflow or any prerequisites. The agent must infer usage from the name and the parenthetical note.

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