Skip to main content
Glama

WhiteMagic — governed local memory for agent continuity

by io.github.lbailey94
OverviewDiscussionsAdmin

Memory revision chain

memory.revisions
Read-onlyIdempotent

List or verify a memory's content revision chain (tamper evidence): every content update is chained and head-checked.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesMemory UUID to inspect
actionNoAction: list (default) | verify
galaxyNoGalaxy (default: codex)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoMemory UUID
countNoNumber of revisions returned
actionNoAction performed (list, restore, ...)
galaxyNoGalaxy containing the memory
statusNoOperation status
revisionsNoRevision records with content hashes and timestamps

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / description
      Previous value: -"Result envelope for this tool; fields vary by operation."New value: +"Revision chain for a memory (newest first)."
    • addedOutput schema / properties
      Added value: +{
+  "action": {
+    "description": "Action performed (list, restore, ...)",
+    "type": "string"
+  },
+  "count": {
+    "description": "Number of revisions returned",
+    "type": "integer"
+  },
+  "galaxy": {
+    "description": "Galaxy containing the memory",
+    "type": "string"
+  },
+  "id": {
+    "description": "Memory UUID",
+    "type": "string"
+  },
+  "revisions": {
+    "description": "Revision records with content hashes and timestamps",
+    "items": {
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "status": {
+    "description": "Operation status",
+    "type": "string"
+  }
+}
  2. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: it explains that every content update is chained and head-checked, which conveys the tamper-evidence mechanism and the verify action's purpose.

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?

A single, front-loaded sentence states the verb, resource, and purpose without wasted words. The parenthetical 'tamper evidence' efficiently communicates the tool's intent, and the chaining detail earns its place by explaining the behavioral guarantee.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, full parameter coverage in the schema, and annotations covering safety and idempotency, the description is nearly complete for an agent to invoke the tool correctly. The only minor gap is that 'head-checked' is not elaborated, though the output schema likely clarifies the returned verification data.

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 description coverage is 100%, so the schema fully documents id, action, and galaxy. The description's 'List or verify' maps to the action parameter but adds no new semantic detail beyond what the schema already provides.

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?

The description states a specific verb ('List or verify') and a specific resource ('a memory's content revision chain'), and adds the purpose ('tamper evidence'). This clearly distinguishes it from siblings like memory.read or memory.search, which deal with current content or retrieval rather than revision history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'tamper evidence' implies the tool is for integrity checking, and the action parameter distinguishes listing from verifying. However, the description does not explicitly state when to use this tool versus alternatives such as memory.read, receipts.verify, or memory.aggregate, nor does it mention any exclusions.

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

All WhiteMagic — governed local memory for agent continuity 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