Skip to main content
Glama

hcl_restore_config

Destructive

Restore a tested native backup and compare the complete running configuration, with gated execution to verify recovery.

Instructions

Restore a tested native backup and compare the complete running configuration (gated).

Input Schema

NameRequiredDescriptionDefault
topologyYes
backup_idYes
project_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, so the mutation profile is known. The description adds useful context: it restores a *tested* backup and performs a running-config comparison afterward, plus a gating condition. However it never states what configuration is overwritten, whether rollback is possible, or what 'gated' concretely requires.

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?

One front-loaded sentence with no filler, and both the restore action and the post-restore comparison are stated up front. '(gated)' is slightly opaque jargon but costs little.

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 destructive, non-idempotent restore with zero schema descriptions and no output schema, the description is thin: preconditions for the gate, what the comparison returns, and failure/rollback behavior are all unaddressed.

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?

Schema description coverage is 0% for all three required parameters (project_path, topology, backup_id), so the schema contributes nothing. The description only loosely implies backup_id via the word 'backup' and says nothing about project_path or topology, leaving the agent to guess formats and relationships.

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 names a specific verb ('Restore') and resource ('tested native backup'), plus secondary behavior ('compare the complete running configuration'). It clearly differs from siblings like hcl_backup_config and hcl_diff, though it never names those siblings explicitly.

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

Usage Guidelines3/5

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

'tested native backup' and '(gated)' imply a precondition (backup must exist and be validated) but only by inference. There is no explicit when-to-use guidance, no exclusions, and no pointer to alternatives such as hcl_backup_config or hcl_diff.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.