Skip to main content
Glama

Preview restoring a site from a backup

fleet__restore_from_snapshot

Preview restoring one site from a SiteVault backup Royally started for it (the backup id fleet__trigger_backups returned). The preview says when the backup was taken, its size and how many posts changed since; SiteVault refuses a backup it cannot restore. Nothing changes here: a person applies the restore in Royally from the approve_url, and it cannot be undone. Follow a started restore with fleet__restore_status.

Input Schema

NameRequiredDescriptionDefault
dry_runNoDefaults to true: preview the change without applying it.
site_idYes
snapshot_idYesThe SiteVault backup id fleet/trigger_backups returned for this site.
acknowledgmentNoConfirmation phrase(s) returned by a previous call that needed approval. Required on some real runs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior1/5

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

Annotations declare readOnlyHint=false, while the description says 'Nothing changes here' and frames the tool as a pure preview. That is a direct contradiction about whether the caller can expect state changes. The description does add useful context about SiteVault refusing unrestorable backups and the irreversible nature of the actual restore, but the read-only contradiction is serious.

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

Conciseness5/5

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

Four sentences, front-loaded with the purpose, then behavioral context, then the follow-up tool. There is no filler, and each sentence contributes to understanding the workflow.

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?

With no output schema, the description usefully explains what the preview returns (backup time, size, number of changed posts) and where the actual restore happens. It omits guidance on the acknowledgment parameter and is undermined by the read-only contradiction, but it is otherwise complete for this complexity level.

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

Parameters3/5

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

Schema description coverage is 75%, so most parameter meaning is already structured. The description adds context for snapshot_id (backup id from fleet__trigger_backups) and implies a preview mode, but site_id remains undocumented and the description does not compensate for the coverage gap.

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

Purpose5/5

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

The description names a specific verb ('Preview restoring') and resource ('one site from a SiteVault backup'), and it ties the tool to the backup id returned by fleet__trigger_backups. This distinguishes it from fleet__restore_status and fleet__trigger_backups without opening either schema.

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

Usage Guidelines4/5

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

The description clearly places the tool as a preview step after fleet__trigger_backups and before fleet__restore_status, and notes that a person applies the restore in Royally. It does not explicitly state when not to use it or contrast it with other preview/restore alternatives, but the workflow context is strong.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources