Skip to main content
Glama
Sign In

Ginta

by app.ginta
OverviewDiscussionsAdmin

Undo: restore a previous version

restore_version
Destructive

Use to undo changes: restores a saved version (numbers from get_site with history: true), pages and live parts (menu prices, products, posts…), as a new version, so it can itself be undone. Visitors' messages, bookings and orders are never changed.

Input Schema

NameRequiredDescriptionDefault
confirmNotrue after the owner agreed to restore although something can't go back (the first answer lists it).
site_idYesThe site id: the first part of the site URL, e.g. "bella-roma" for https://bella-roma.ginta.page (see list_sites).
versionYesVersion number to restore.

Output Schema

NameRequiredDescriptionDefault
urlYesThe site's address.
textYesThe answer in words, the same as the text content: read it (for get_guide the whole guide, for get_site the files' contents).
partsNoLive parts that went back too ("menu"…).
versionYesThe new live version.
not_restoredNoWhat couldn't go back, in plain sentences.
restored_fromYesThe version that was restored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / text
      Added value: +{
+  "description": "The answer in words, the same as the text content: read it (for get_guide the whole guide, for get_site the files' contents).",
+  "type": "string"
+}
    • changedOutput schema / required
      Previous value: -[
-  "url",
-  "version",
-  "restored_from"
-]New value: +[
+  "url",
+  "version",
+  "restored_from",
+  "text"
+]
  2. Changed3 schema fields changed
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "true after the owner agreed to restore although something can't go back (the first answer lists it).",
+  "type": "boolean"
+}
    • addedOutput schema / properties / not_restored
      Added value: +{
+  "description": "What couldn't go back, in plain sentences.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / parts
      Added value: +{
+  "description": "Live parts that went back too (\"menu\"…).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, yet the description still adds real value: it explains that the restore is written as a NEW version and is therefore itself undoable, and it enumerates what is never touched (visitors' messages, bookings, orders). The 'first answer lists it' / confirm flow is only implied here and fully documented in the schema.

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 the purpose first, then scope, then exclusions. The stacked parentheticals ('menu prices, products, posts…') add minor clutter but each clause carries information.

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?

For a destructive mutation with rich annotations and an output schema, the description covers the origin of the version identifier, the blast radius, undoability and what is preserved. The mandatory confirmation-on-partial-restore path is delegated to the schema's confirm description, which is acceptable but leaves a small gap.

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 is 3, but the description earns more by explaining where version numbers come from (get_site with history: true) and that a restore may proceed even when part of the state cannot be reverted. That adds meaning beyond the bare 'Version number to restore' property text.

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?

States a specific verb and resource ('restores a saved version') with concrete scope: pages and live parts such as menu prices, products and posts. It is unmistakably distinct from update_site or manage_site because it operates on a numbered historical version rather than current settings.

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?

Opens with an explicit trigger ('Use to undo changes') and points to get_site with history: true as the source of valid version numbers, which tells the agent how to obtain the input. It stops short of naming an alternative tool or an explicit when-not-to-use condition.

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

All Ginta toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources