Skip to main content
Glama

restore_document_version

Destructive

Restore a document's content from a listed version or snapshot to revert unwanted changes; this updates current content, queues reindexing, and does not recover trashed documents.

Instructions

Restore content from a version or snapshot listed by read_document(view=versions). This changes current content and queues indexing; it does not restore a trashed document.

Input Schema

NameRequiredDescriptionDefault
versionIdYesUUID returned by the corresponding list or read operation.
documentIdYesUUID returned by the corresponding list or read operation.
workspaceIdNoWorkspace UUID from list_workspace_structure(kind=workspaces). Required for ambiguous creates and structure changes; omit to search all granted scopes.

Output Schema

NameRequiredDescriptionDefault
idYes
tagsNo
titleYes
contentYes
ownerIdYes
folderIdYes
metadataNo
createdAtYes
updatedAtYes
categoryIdYes
folderNameNo
visibilityYes
contentJsonNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv2.0.4
    • addedInput schema / properties / workspaceId
      Added value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "description": "Workspace UUID from list_workspace_structure(kind=workspaces). Required for ambiguous creates and structure changes; omit to search all granted scopes.",
      +  "format": "uuid",
      +  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +  "type": "string"
      +}
    • removedOutput schema / properties / categoryId / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / categoryId / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / folderId / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / folderId / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / folderName / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / folderName / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / tags / items / properties / color / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / tags / items / properties / color / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed3 schema fields changedv0.1.2
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / documentId / description
      Previous value: -"UUID of the document whose content should be restored; it must be visible in the active workspace or category."New value: +"UUID returned by the corresponding list or read operation."
    • changedInput schema / properties / versionId / description
      Previous value: -"UUID of a version belonging to this document, from get_version_history. Use the version ID, not a snapshot label."New value: +"UUID returned by the corresponding list or read operation."
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is known. The description adds real behavioral context beyond that: current content is overwritten and an indexing job is queued as a side effect. It stops short of saying whether the prior content is itself snapshotted or whether the restore is reversible.

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, no filler. The core mutation and the queued-indexing consequence come first, and the exclusion follows as a scoping clause. Every 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?

Output schema and annotations already cover the return shape and safety profile, so the description only needs to explain side effects and boundaries — which it does. The only gap is not stating whether a rollback snapshot is created before overwriting current content.

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?

With 100% schema coverage the baseline is 3, but the description adds a retrieval path for versionId ('listed by read_document(view=versions)') that is more actionable than the schema's generic 'UUID returned by the corresponding list or read operation.' workspaceId and the required UUID pairing are left to the schema.

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 the specific verb and resource (restore content from a version/snapshot) and immediately scopes it against the sibling restore_trashed_document with 'it does not restore a trashed document.' An agent can distinguish it from the other 20 siblings without reading any 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?

Tells the agent where the versionId comes from (read_document with view=versions), which is a concrete precondition for use. It also excludes the trashed-document case, implicitly routing that need to restore_trashed_document, though it never names that sibling explicitly.

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