Skip to main content
Glama
S-CurveLabs

io.github.S-CurveLabs/sqlglass

Official
by S-CurveLabs

restore_snapshot

Destructive

Restore queries to a previous snapshot to reverse unwanted changes. Supports dry-run previews and reversible restores.

Instructions

Put the queries in a snapshot back to how they were before that write ('latest' = undo the last write). The restore is itself snapshotted, so it can be undone too.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNo
snapshot_idNolatest

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

The description adds meaningful behavioral context beyond the destructiveHint annotation by stating that the restore is itself snapshotted and can be undone. This usefully tempers the destructive nature of the tool. It does not mention authorization or effects on other snapshots, but the annotation plus added context cover the key behavioral risk.

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?

Two sentences with no filler. The core action and the important 'latest' behavior come first, followed by the undoable-restore trait. Every sentence earns its place.

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

Completeness3/5

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

The core restore semantics and reversibility are clear, but the tool has no output schema and the description does not mention what a call returns or how dry_run=true behaves. An agent cannot fully predict the outcome of the dry-run parameter or the response format, leaving a meaningful gap.

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?

With 0% schema description coverage, the description must compensate for parameter meaning. It explains the 'latest' default for snapshot_id but does not explain dry_run at all, nor does it clarify what a snapshot_id is or how to obtain one. This is incomplete compensation for an otherwise undocumented parameter set.

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 clearly states what the tool does: it reverts queries in a snapshot to their state before a write, with 'latest' explicitly meaning 'undo the last write.' This is specific and distinct from sibling tools like list_snapshots or save_query, and it gives actionable meaning to the default parameter value.

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 provides practical context by explaining that 'latest' means undo the last write, which tells an agent when to invoke this tool. It does not explicitly enumerate alternatives or exclusions, but no sibling tool appears to compete with this restore behavior, so the guidance is sufficient.

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