Skip to main content
Glama
Sign In

Squish

by co.squish
OverviewDiscussionsAdmin

Restore my site backup

restore_my_site_backup
Destructive

Restores one of the customer's SHARED hosting sites from a restore point. DESTRUCTIVE. A nightly point is merged over the whole live site, so changes made since it was taken are lost (files added since may survive). An edit point (backupId "edit_…") puts back ONLY the files that write replaced, after setting their current versions aside as a new edit point, so it can itself be undone. Two-step: (1) call with confirm:false — the preview names the restore point and says exactly what will change; read it to the customer and ask for an explicit yes. (2) ONLY after an explicit yes in their most recent message, call with confirm:true. Get backupId from list_my_backups; never guess one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>",
      "backupId": "<backupId>"
    },
    "name": "restore_my_site_backup"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainYesThe hosted site's domain.
confirmNofalse (default) returns the preview; true restores. Pass true ONLY after explicit user confirmation.
backupIdYesA backupId from list_my_backups.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, but the description goes well beyond them: it explains that a nightly point merges over the whole live site, that changes since it was taken are lost while added files may survive, and that an edit point restores only the files a write replaced while setting current versions aside so the restore itself can be undone. That is precisely the consequence detail an agent needs before invoking a destructive operation.

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?

Front-loads the DESTRUCTIVE warning and the point-type distinction before the procedural steps, so the most important facts land first. It is dense and long-ish, but nearly every sentence carries decision-relevant information; only the parenthetical about surviving files is slightly hedged.

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

Completeness5/5

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

For a destructive, non-idempotent tool with no output schema, the definition covers scope, data-loss consequences, reversibility, the confirmation gate, and where to obtain the required identifier. Nothing an agent needs in order to call it safely is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning: the backupId "edit_…" prefix selects a fundamentally different restore behavior, and confirm:false is characterized as returning a preview that names the restore point and what will change. These are semantic distinctions the schema text alone does not convey.

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?

Opens with a specific verb and resource ("Restores ... SHARED hosting sites from a restore point") and immediately distinguishes two restore-point types, nightly versus edit. An agent can tell this apart from list_my_backups or write_site_files without opening the schema.

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

Usage Guidelines5/5

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

Gives an explicit two-step protocol: call with confirm:false first, read the preview to the customer, then call with confirm:true only after an explicit yes in the most recent message. It also names the sibling that supplies backupId (list_my_backups) and forbids guessing one.

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

All Squish toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources