Skip to main content
Glama

AvianSuite

by com.aviansuite
OverviewDiscussionsAdmin

Undo changes

undo_changes

Use to reverse one agent's changes in a time window, for example after a bad import or a runaway loop, or to restore the store to a checkpoint saved with save_checkpoint by reversing every change made after it. Pass since for a window, or checkpoint to restore; with a checkpoint, actor is optional and limits the restore to that agent. By default this is a dry run that lists what would be reversed and returns the absolute until (and since) it used. Call again with those exact values, its plan_id and confirm: true to write the reversals; a confirmed call refuses a relative since. Each reversal is a new retraction, so an undo can itself be undone. Only facts can be undone; other events are listed as skipped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorNoThe actor whose changes to reverse, as shown by list_changes. Required with since; optional with checkpoint.
sinceNoStart of the window: an RFC 3339 time, or a duration back from now such as 30m, 2h or 24h. Give since or checkpoint, not both.
untilNoEnd of the window, RFC 3339. Defaults to now on a dry run. Required with confirm, with the value the dry run returned.
reasonNoWhy the changes are being undone. Recorded on every reversal.
confirmNoSet true to write the reversals. Leave unset for a dry run.
plan_idNoThe plan_id the dry run returned. When set, confirm refuses to write if the changes in the window are no longer the ones the dry run showed.
entity_idNoOnly reverse changes to this entity.
workspaceNoOptional. The workspace to act on, as list_workspaces names it. Leave it out to use this connection's first workspace.
checkpointNoName of a checkpoint saved with save_checkpoint. Reverses the changes made after it, restoring the facts to that state. Give since or checkpoint, not both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / actor / description
      Previous value: -"The actor whose changes to reverse, as shown by list_changes."New value: +"The actor whose changes to reverse, as shown by list_changes. Required with since; optional with checkpoint."
    • addedInput schema / properties / checkpoint
      Added value: +{
+  "description": "Name of a checkpoint saved with save_checkpoint. Reverses the changes made after it, restoring the facts to that state. Give since or checkpoint, not both.",
+  "type": "string"
+}
    • changedInput schema / properties / since / description
      Previous value: -"Start of the window: an RFC 3339 time, or a duration back from now such as 30m, 2h or 24h."New value: +"Start of the window: an RFC 3339 time, or a duration back from now such as 30m, 2h or 24h. Give since or checkpoint, not both."
    • removedInput schema / required
      Removed value: -[
-  "actor",
-  "since"
-]
  2. Changed1 schema field changed
    • addedInput schema / properties / workspace
      Added value: +{
+  "description": "Optional. The workspace to act on, as list_workspaces names it. Leave it out to use this connection's first workspace.",
+  "type": "string"
+}
  3. Changed2 schema fields changed
    • addedInput schema / properties / plan_id
      Added value: +{
+  "description": "The plan_id the dry run returned. When set, confirm refuses to write if the changes in the window are no longer the ones the dry run showed.",
+  "type": "string"
+}
    • changedInput schema / properties / until / description
      Previous value: -"End of the window, RFC 3339. Defaults to now."New value: +"End of the window, RFC 3339. Defaults to now on a dry run. Required with confirm, with the value the dry run returned."
  4. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false and destructiveHint=false; the description explains why the operation is non-destructive ('each reversal is a new retraction, so an undo can itself be undone') and adds behavior annotations do not carry: dry-run by default, drift protection via plan_id, and that non-fact events are listed as skipped rather than reversed.

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?

Front-loaded with the trigger scenarios, then the two modes, then the dry-run/confirm contract. Every sentence carries a distinct rule (mode selection, confirmation, idempotency of the undo itself, skipped events) with no filler.

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 9-parameter, zero-required, no-output-schema tool with a two-phase write protocol, the description covers everything an agent needs: how to pick parameters, what the dry run returns, how to confirm, and what happens to non-fact events. Nothing material is left to inference.

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%, so the baseline is 3, but the description adds real cross-parameter semantics the schema does not: since and checkpoint are alternatives, actor is optional specifically when checkpoint is used, until must be the absolute value the dry run returned, and confirm+plan_id together guard against stale windows.

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+resource (reverse changes) and immediately scopes it to two concrete scenarios (a bad import or runaway loop, and restoring to a checkpoint from save_checkpoint). This cleanly distinguishes it from siblings like retract_fact, correct_fact and save_checkpoint, which an agent could otherwise confuse with it.

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?

Gives explicit when-to-use conditions, names the two mutually exclusive entry points (since for a window, checkpoint to restore), and spells out the required follow-up workflow (dry run first, then re-call with the returned until/since, plan_id and confirm: true). It also states a hard exclusion: a confirmed call refuses a relative since.

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

All AvianSuite toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources