Skip to main content
Glama
Sign In

Pixelesq

by com.pixelesq
OverviewDiscussionsAdmin

Roll a revision back to a version

revert_page_revision_to_version
Destructive

Undo recent saves on a page's current draft: keeps the saves up to and including saveNumber and deletes every newer one. Read get_page_revisions first: the draft head (isDraftHead) lists its saves as [{ number, savedAt }] and its headAnchor. Pass that revision id, the save number to keep, and the headAnchor as expectedHeadAnchor. 0 keeps none of the draft's saves (back to the state the draft started from). Edits one person makes within about five minutes of each other share one save number, so undoing that number undoes all of them.

Refused unless the revision is the page's current draft (not the published one), the draft has not changed since the headAnchor was read, and a newer save exists. WARNING: deleted saves cannot be recovered.

Input Schema

NameRequiredDescriptionDefault
pageIdYesThe page the revision belongs to
versionNoOlder name for saveNumber
projectIdYesThe project ID
revisionIdYesThe draft head revision id (isDraftHead in get_page_revisions)
saveNumberNoKeep the saves up to and including this number (from get_page_revisions saves); newer ones are deleted
expectedHeadAnchorYesThe draft head's headAnchor from get_page_revisions; the undo is refused if the draft changed since

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / expectedHeadAnchor
      Added value: +{
+  "description": "The draft head's headAnchor from get_page_revisions; the undo is refused if the draft changed since",
+  "type": "string"
+}
    • addedInput schema / properties / pageId
      Added value: +{
+  "description": "The page the revision belongs to",
+  "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"
+}
    • changedInput schema / properties / revisionId / description
      Previous value: -"The revision ID whose versions to roll back"New value: +"The draft head revision id (isDraftHead in get_page_revisions)"
    • addedInput schema / properties / saveNumber
      Added value: +{
+  "description": "Keep the saves up to and including this number (from get_page_revisions saves); newer ones are deleted",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}
    • changedInput schema / properties / version / description
      Previous value: -"Keep versions up to and including this number; delete all newer ones. 0 keeps none (back to the revision's base state)."New value: +"Older name for saveNumber"
    • changedInput schema / required
      Previous value: -[
-  "projectId",
-  "revisionId",
-  "version"
-]New value: +[
+  "projectId",
+  "pageId",
+  "revisionId",
+  "expectedHeadAnchor"
+]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructiveHint=true annotation by disclosing that deleted saves are unrecoverable, that the operation is refused unless the revision is the current draft and the anchor still matches (optimistic concurrency), and that edits within ~5 minutes collapse into one save number. This is rich behavioral context an agent needs before a destructive call.

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-loaded with the core operation, then prerequisites, edge cases, refusal conditions, and the destructive warning. Dense but every sentence carries information; the only cost is that the paragraph runs long enough that the WARNING could be surfaced earlier.

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 mutation with no output schema, it covers the workflow prerequisite, anchor-based concurrency check, save-number edge case, and irreversibility. Nothing material is missing for an agent to call it correctly.

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%, but the description still adds meaning: it maps revisionId to the isDraftHead entry, explains that saveNumber=0 keeps none of the draft's saves, and clarifies that expectedHeadAnchor is the stale-read guard. It does not explain the 'version' alias parameter, a minor omission.

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 ('Undo recent saves on a page's current draft') and defines the exact operation: keep saves up to saveNumber, delete all newer ones. The draft-only scope and save-number semantics distinguish it from the sibling revert_page_revision without needing to open either 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?

Explicitly tells the agent to read get_page_revisions first and pass the head revision id, save number, and headAnchor. It also enumerates the refusal conditions (revision must be the current draft, headAnchor must be unchanged, a newer save must exist), so when-not-to-use is covered as clearly as when-to-use.

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

All Pixelesq 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