Skip to main content
Glama

Restore a version or preview

rollback
Destructive

Makes an earlier version or a preview live as a new version (versions are never deleted); a conflict if the site changed since base_revision. discard: true deletes a preview.

Input Schema

NameRequiredDescriptionDefault
siteYes
discardNoWith a preview id: delete it
revisionYesRevision id or version number (list_versions), or a preview id (get_site previews)
site_tokenNoFrom an anonymous deploy (secret)
base_revisionYesThe live revision id you last saw

Output Schema

NameRequiredDescriptionDefault
revisionNo
agent_messageNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / discard / description
      Previous value: -"With a preview id: deletes that preview instead"New value: +"With a preview id: delete it"
    • addedInput schema / properties / site_token / description
      Added value: +"From an anonymous deploy (secret)"
  2. Changed3 schema fields changed
    • removedInput schema / properties / site / description
      Removed value: -"Site name"
    • removedInput schema / properties / site_token / description
      Removed value: -"From the first deploy (no account)"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "agent_message": {
      +      "type": "string"
      +    },
      +    "revision": {
      +      "properties": {
      +        "id": {
      +          "type": "string"
      +        },
      +        "number": {
      +          "type": "number"
      +        }
      +      },
      +      "type": "object"
      +    }
      +  },
      +  "type": "object"
      +}
  3. Changed5 schema fields changed
    • addedInput schema / properties / discard
      Added value: +{
      +  "description": "With a preview id: deletes that preview instead",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / revision / description
      Previous value: -"Revision id or version number (list_versions)"New value: +"Revision id or version number (list_versions), or a preview id (get_site previews)"
    • changedInput schema / properties / site / description
      Previous value: -"Site name, e.g. brave-otter-4821"New value: +"Site name"
    • changedInput schema / properties / site_token / description
      Previous value: -"site_token from the first deploy (anonymous sites only)"New value: +"From the first deploy (no account)"
    • changedOutput schema / (root)
      Previous value: -{
      -  "additionalProperties": {},
      -  "properties": {
      -    "agent_message": {
      -      "type": "string"
      -    },
      -    "confirm_token": {
      -      "type": "string"
      -    },
      -    "error": {
      -      "description": "On failure (isError): {code, message}"
      -    }
      -  },
      -  "type": "object"
      -}New value: +null
  4. Changed2 schema fields changed
    • addedInput schema / properties / revision / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "exclusiveMinimum": 0,
      +    "type": "integer"
      +  }
      +]
    • removedInput schema / properties / revision / type
      Removed value: -"string"
  5. Changed1 schema field changed
    • changedInput schema / properties / revision / description
      Previous value: -"Revision id or version number (get_site versions: true)"New value: +"Revision id or version number (list_versions)"
  6. First observed

TDQS

A3.9/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. The description adds valuable non-obvious behavior: versions are never deleted, a conflict occurs if the site changed since base_revision, and discard=true deletes a preview. This is meaningful context beyond the annotations, though auth details for site_token are left to 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.

Conciseness5/5

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

The description is a single compact sentence with no wasted words. The core mutation and non-deletion guarantee are front-loaded, followed by the two operational caveats.

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, non-idempotent mutation with an output schema and annotations, the description supplies the key behavioral facts an agent needs: non-deletion, conflict semantics, and preview discard. It does not cover the site_token secret or return format, but the output schema and parameter schema reduce the need.

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 description coverage is high at 80%, so the baseline is 3. The description still adds consequence-level semantics for base_revision ('conflict if the site changed since base_revision') and for discard ('deletes a preview'), which goes beyond the schema's terse parameter notes.

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 uses a specific verb ('Makes ... live as a new version') and resource ('an earlier version or a preview'), clearly distinguishing rollback from list_versions or get_site. It does not explicitly name a sibling alternative, which keeps it just short of a 5.

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?

It implies usage via the conflict condition ('a conflict if the site changed since base_revision') and the discard flag for previews. However, it does not state when to choose rollback versus deploy, preview_as_user, or list_versions, leaving alternatives unaddressed.

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