Skip to main content
Glama

vrrp_set

Configure VRRP on a DrayTek Vigor 3912S router. This write operation requires confirmation to apply the changes.

Instructions

Configure VRRP (write — requires confirmation)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramYes
user_codeNo
confirm_tokenNo
confirmation_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

C2.7/5.0
Behavior3/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. It does disclose two meaningful behaviors — that this is a write operation and that confirmation is required — which is genuinely useful context beyond the schema. But it does not explain the confirmation round-trip (how confirm_token/confirmation_id relate), whether the change is applied immediately or only after confirm_token, or what side effects the write has.

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?

The description is eight words with zero padding, and the key facts (configure, write, confirmation) are front-loaded. It earns near-maximum for efficiency, though it is slightly dense: the parenthetical 'write — requires confirmation' would read more clearly as separate statements.

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?

For a write tool with no annotations, no output schema, 0% schema coverage, and a two-step confirmation flow implied by confirm_token/confirmation_id, the description is far too thin. An agent cannot know what to pass in 'param' or how the confirmation handshake works, making it risky to invoke correctly.

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%, so the description must compensate for the four parameters, but it mentions nothing about param (required), user_code, confirm_token, or confirmation_id beyond the bare 'requires confirmation' phrase. The required 'param' string is completely undocumented, leaving an agent unable to infer valid values or formats.

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 states a specific verb ('Configure') and resource (VRRP), and the 'write' tag implicitly separates it from sibling read tools like vrrp_show and from vrrp_enable/vrrp_apply/vrrp_reset, which name distinct operations. However, 'Configure VRRP' is broad and doesn't say which aspects of VRRP can be set, so an agent still can't tell exactly what domain it covers.

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?

There is no explicit guidance on when to use this tool versus vrrp_enable, vrrp_apply, or vrrp_reset, and no exclusions or prerequisites are stated. The 'requires confirmation' hint implies this is the appropriate choice when a confirmed write is needed, but that is left to inference rather than stated.

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