Skip to main content
Glama

Typebar (formerly SuperDocs)

redo_revert

Revert is non-destructive: this restores the session FORWARD to the pre-revert state (returned by the revert as redo_checkpoint_id), restores the document to that state while still merging any concurrent edits from other sessions (keeping both where they conflict), and un-archives exactly the chat turns the revert hid. Intended for use immediately after a revert; once a new message is sent the timeline diverges and the web app stops offering it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
window_idNoOptional identifier for the client window issuing the request, used to coordinate concurrent reverts from multiple browser tabs.
session_idYes
turn_indexYesThe turn the revert rewound to (rows at/after this were archived); redo un-archives exactly those.
authorizationNo
redo_checkpoint_idYesThe identifier of the pre-revert state, returned by the revert response.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dry_runNoEchoes the request's dry_run: when true nothing was committed/archived — this is a preview only.
session_idYesSession identifier.
compose_textYesThe text of the user message that was reverted. Clients should pre-fill the compose box with this so the user can edit and resend.
editor_actionNoClient instruction: 'update' to load the restored document, or 'clear' to reset the editor to empty.update
document_stateNoRestored document state. Null when the session is reset to empty.
revert_changesNoPer-document (slug -> change-set) revert diff. Applying these merges the revert onto any concurrent live edits — a conflicting section is surfaced for you to resolve rather than replacing the whole document. On dry_run this is the preview; on a real revert it is what was committed.
revert_conflictsNoPer-document (slug -> entries) sections whose restore did NOT fully land. TWO classes, told apart by the 'displaced' flag. (1) NOT LANDED ('displaced' absent/false): content another writer committed was preserved instead (reason 'concurrent_edit_preserved' / 'lineage_unknown'), or a removal could not be resolved against the live document; the matching revert_changes entry is annotated 'conflict': true and carries the preserved bytes as new_html (the honest committed state) plus the un-landed restore as restore_html. (2) LANDED IN THE WRONG PLACE ('displaced': true): the content WAS restored but not at its original position — reason 'restored_elsewhere' (it was added at the end of the document because the section it anchors to is gone) or 'position_not_restored' (a concurrent writer's placement won). These carry an empty their_html (nothing of another writer's was preserved, so there is nothing to adopt) plus the raw 'resolution' token, and the matching revert_changes entry is annotated 'displaced': true — never 'conflict', because new_html is still the restored content. (3) NOT SAVED AT ALL ('write_failed': true, operation 'write', chunk_id null): the document's recovery write did not commit — reason 'document_deleted' (archived mid-revert), 'storage_paused' (durable saving paused for this account) or 'write_failed'. Document-level, so there is no matching revert_changes entry; storage still holds the pre-revert content while document_state shows the reverted document, so a client MUST re-read the document before saving again. Null/absent when the revert landed cleanly everywhere.
reverted_to_turnYesTurn index that the active conversation now ends at (the AI reply preceding the reverted user message). -1 when the session is reset to its initial empty state (revert from the very first user message).
redo_checkpoint_idNoThe identifier of the pre-revert state. Revert is non-destructive — passing this back to POST /sessions/{id}/redo (with the same turn_index) restores it and un-archives the rolled-back turns, undoing the revert. Null on a dry-run, and null when the pre-revert state could not be captured — in that case redo_unavailable_reason says which, so absence by design and absence by failure are never the same value.
archived_turn_countYesNumber of chat rows soft-archived by this revert (turns hidden from the UI but retained for audit).
redo_unavailable_reasonNoPresent ONLY when redo_checkpoint_id is null because the pre-revert state could not be captured (never on a dry-run, where null is by design). The revert itself succeeded and is durable; what is unavailable is the one-step undo of it. Treat a non-null value as: do not attempt redo_revert for this revert — it has no argument to pass.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries full burden and does well: it declares the operation non-destructive, explains conflict merging ('keeping both where they conflict'), and specifies exactly what is un-archived. It omits any authorization/permission requirements, which is the main remaining gap.

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?

The key trait ('Revert is non-destructive') is front-loaded and the sentences are dense and purposeful. The trailing intended-use sentence is valuable but the overall block is slightly overloaded for a single tool.

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?

An output schema exists, so return values need not be explained, and the description covers the state-change semantics, the temporal usage window, and the checkpoint provenance. For a revert tool with annotations absent, this is complete enough to call correctly.

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

Parameters3/5

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

Schema coverage is 60%, so the schema already documents turn_index and redo_checkpoint_id. The description reinforces that redo_checkpoint_id comes from the revert response and that turn_index marks the rewind point, but adds little syntax or format meaning, and says nothing about window_id or authorization.

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?

States a specific verb+resource (revert forward / redo a revert) and precisely describes the resulting state change (restores session, document, un-archives chat turns). It does not name the sibling revert_session_to_message, so an agent must infer the pairing, keeping this below 5.

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?

Explicit when-to-use ('intended for use immediately after a revert') and when-not ('once a new message is sent the timeline diverges and the web app stops offering it'). The temporal constraint that selects this tool over any alternative is fully spelled out.

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.