Skip to main content
Glama
phillipclapham

anneal-memory

by phillipclapham
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

wrap_cancel

Clear an abandoned in-progress wrap so prepare_wrap can run again, keeping episodes; use when prepare_wrap refuses because a wrap is already in progress.

Instructions

Abandon a wrap that is in progress, clearing the wrap-in-progress state so a fresh prepare_wrap can run. Call this when prepare_wrap refuses with 'a wrap is already in progress' and that wrap is NOT going to be finished — typically one an earlier session opened and then ended without saving, so nothing is left to compress it. Episodes are NOT deleted: cancelling discards the frozen snapshot and its handshake token, and every episode in the abandoned window is still recorded and is picked up by the next prepare_wrap. The cancellation is written to the audit trail with the abandoned token and episode IDs. Check who owns the wrap before cancelling it. One server process runs per client session against a shared store, so the wrap may belong to another session that is still running and part-way through composing its compression; cancelling makes that session's save fail and throws its work away. Call status first — it reports when the wrap started, and one opened moments ago is probably a live peer rather than a corpse. Prefer finishing a wrap you opened yourself. Do not call this to recover from a save_continuity validation failure you can fix by editing the text and saving again — that wrap is still live and cancelling it throws away the snapshot you are working against. If you opened the wrap yourself, pass the wrap_token prepare_wrap gave you: the cancel then succeeds only if that wrap is still the one in progress, and is refused without changing anything if a peer replaced it. Omit wrap_token to cancel whatever is current, which is what you want when recovering a wrap you did not open. Exception: a wrap prepared under the consolidate gate is cancelled without its token only when session_id is the session that prepared it, or with force=true when that session is gone; a wrap opened with a token its preparer supplied is cancelled without that token only with force=true. PARTIAL (corrupt) wrap state is cleared with partial=true, which refuses if a healthy wrap has replaced it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoCancel a gated wrap without its token or session, or a wrap opened with a caller-supplied token without that token, when its preparer is gone. Discards its compression.
partialNoClear PARTIAL (corrupt, unsaveable) wrap state, and only that: refused with no change if a healthy wrap is in progress or the store is idle. Needs no token. Cannot be combined with wrap_token.
session_idNoYour session. Without wrap_token, a wrap prepared under the consolidate gate is cancelled only when this is the session that prepared it.
wrap_tokenNoOptional proof that the wrap being cancelled is yours — the token prepare_wrap returned. The store compares it inside the same transaction that clears, so a peer cannot swap the wrap in between. Refused with no change if it does not match, including when the wrap has already completed. Omit it to cancel whatever is in progress (a gated wrap also needs session_id or force; a wrap opened with a caller-supplied token needs force).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.9.41
    • changedInput schema / properties / force / description
      Previous value: -"Cancel a gated wrap without its token or session, when the session that prepared it is gone. Discards its compression."New value: +"Cancel a gated wrap without its token or session, or a wrap opened with a caller-supplied token without that token, when its preparer is gone. Discards its compression."
    • changedInput schema / properties / wrap_token / description
      Previous value: -"Optional proof that the wrap being cancelled is yours — the token prepare_wrap returned. The store compares it inside the same transaction that clears, so a peer cannot swap the wrap in between. Refused with no change if it does not match, including when the wrap has already completed. Omit it to cancel whatever is in progress (a gated wrap also needs session_id or force)."New value: +"Optional proof that the wrap being cancelled is yours — the token prepare_wrap returned. The store compares it inside the same transaction that clears, so a peer cannot swap the wrap in between. Refused with no change if it does not match, including when the wrap has already completed. Omit it to cancel whatever is in progress (a gated wrap also needs session_id or force; a wrap opened with a caller-supplied token needs force)."
  2. Changed1 schema field changedv0.9.26
    • addedInput schema / properties / partial
      Added value: +{
+  "description": "Clear PARTIAL (corrupt, unsaveable) wrap state, and only that: refused with no change if a healthy wrap is in progress or the store is idle. Needs no token. Cannot be combined with wrap_token.",
+  "type": "boolean"
+}
  3. Changed3 schema fields changedv0.9.23
    • addedInput schema / properties / force
      Added value: +{
+  "description": "Cancel a gated wrap without its token or session, when the session that prepared it is gone. Discards its compression.",
+  "type": "boolean"
+}
    • addedInput schema / properties / session_id
      Added value: +{
+  "description": "Your session. Without wrap_token, a wrap prepared under the consolidate gate is cancelled only when this is the session that prepared it.",
+  "type": "string"
+}
    • changedInput schema / properties / wrap_token / description
      Previous value: -"Optional proof that the wrap being cancelled is yours — the token prepare_wrap returned. The store compares it inside the same transaction that clears, so a peer cannot swap the wrap in between. Refused with no change if it does not match, including when the wrap has already completed. Omit it to cancel whatever is in progress."New value: +"Optional proof that the wrap being cancelled is yours — the token prepare_wrap returned. The store compares it inside the same transaction that clears, so a peer cannot swap the wrap in between. Refused with no change if it does not match, including when the wrap has already completed. Omit it to cancel whatever is in progress (a gated wrap also needs session_id or force)."
  4. Addedv0.9.15

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description fully discloses side effects: episodes remain recorded, snapshot and token discarded, audit trail entry, impact on peer sessions, token/force semantics, and partial state handling. This is exceptionally rich behavioral context.

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 description is thorough and front-loads the core purpose, but it is a dense single paragraph with some redundancy (e.g., checking ownership and calling status are mentioned separately). Given the tool's complexity, the length is largely justified.

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?

No output schema or annotations exist, yet the description covers all necessary behavioral context: side effects, edge cases, interaction with other tools, and recovery scenarios. It is complete for an agent to invoke 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 100% and each parameter already has a detailed standalone description; the tool description integrates them into workflow guidance but adds little new meaning beyond what the schema already provides for force, partial, session_id, and wrap_token.

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 (Abandon/cancel) and resource (in-progress wrap), and explicitly distinguishes from prepare_wrap, save_continuity, and status by describing the exact condition and what it does not do (episodes not deleted). An agent can tell it apart from siblings without opening schemas.

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?

Provides detailed when-to-use (prepare_wrap refuses with 'a wrap is already in progress' and wrap not going to be finished), when-not (save_continuity validation failure fixable by editing), and alternatives (check status first, prefer finishing your own wrap). Nothing is left to inference.

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

Deploy Server

Other Tools