Skip to main content
Glama

Typebar (formerly SuperDocs)

revert_session_to_message

Rewinds a chat session to the state immediately before a specific user message. The document, conversation history, and supporting context all snap back to that point. The text of the reverted message is returned (compose_text) so the caller can edit and resend it. Messages from the reverted turn forward are soft-archived: hidden from active reads but retained for audit. The original conversation is preserved server-side; the restored conversation becomes the active timeline. Rejects with 409 if the session has a chat job in progress or awaiting approval — wait for the job to settle before reverting. Returns 422 (code 'turn_has_no_restore_point') when the turn recorded no restore point — typically because the message before it did not finish normally; the response carries revertable_turns, a possibly-empty list of turns that can be rewound to.

Input Schema

NameRequiredDescriptionDefault
dry_runNoWhen true, compute the per-document revert diff WITHOUT committing or archiving anything — used to render a preview before the user confirms.
window_idNoOptional identifier for the client window issuing the revert, used to coordinate concurrent reverts from multiple browser tabs.
session_idYes
turn_indexYesTurn index of the user message to revert. The text of that message is returned in compose_text so the caller can re-edit and resend it. Every chat row at this turn or later is soft-archived (hidden from active reads but retained for audit).
authorizationNo

Output 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.

No schema history has been recorded yet.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations present, the description carries the full behavioral burden and does so richly: it discloses soft-archive semantics (hidden from active reads, retained for audit), that the original conversation is preserved server-side, which timeline becomes active, and two specific failure modes (409 in-progress job, 422 'turn_has_no_restore_point' with a revertable_turns payload).

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 action and its effects, then failure handling; every sentence carries information. It is dense but slightly over-long, and the error-code detail could be compressed without losing meaning.

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 described, and the description still covers mutation side effects, timeline state, and both error paths with remediation hints. For a destructive rewind tool with no annotations, nothing critical is missing.

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 only 60%, so the description must compensate; it explains turn_index's downstream effect (message text returned in compose_text, all rows at that turn or later archived) and surfaces the revertable_turns field returned on error. However, session_id and authorization are left entirely undocumented, so the gap is not fully closed.

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 precise verb+resource+scope: 'Rewinds a chat session to the state immediately before a specific user message,' and enumerates exactly what snaps back (document, history, context). An agent can distinguish this rewind operation from siblings like redo_revert without opening a 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?

Gives clear triggering context ('rewind to the point before a user message') and precondition states (wait for a chat job to settle before reverting; job-in-progress yields 409). It does not explicitly name the inverse sibling redo_revert or say when to undo a revert, so alternative-routing guidance is incomplete.

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.