Skip to main content
Glama
MerakOsiris

MemoryGuard

by MerakOsiris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

memoryguard_memory_update

Correct a known memory's body, kind, recall policy, or priority, and commit related rule updates atomically with revision checks; preview validates without saving.

Instructions

Use when owner must correct body, kind, recall policy, or priority of one known memory. Use related_updates with expected revisions, reason and retry key to replace linked rules atomically; preview validates the final package without committing. This recovery entrance remains available when bootstrap is blocked. Do not use to create a record, change lifecycle status, or modify another owner's memory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNonew body
kindNoreplacement kind; omit to preserve current kind
reasonNoaudit reason required for related updates or preview
atom_idNoV2 atom ID; use the source-mapping target when a migrated logical ID is ambiguous
previewNorun the atomic update and budget checks, then roll back; requires expected_revision, idempotency_key and reason
audienceNoreplace mandatory-rule assignments; only allowed for always records
priorityNonew priority
memory_idYesmemory record ID
idempotency_keyNooptional retry key bound to this target and payload
related_updatesNoadditional owner-controlled replacements committed together; every item requires memory_id and expected_revision; accepts body, kind, injection_policy, priority, audience and atom_id
injection_policyNonew injection policy
agent_instance_idNooptional identity consistency check; trusted MCP environment is authoritative
expected_revisionNoreject stale edits; required for every target in related updates or preview

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.7.15
    • addedInput schema / properties / expected_revision
      Added value: +{
+  "description": "reject stale edits; required for every target in related updates or preview",
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / preview
      Added value: +{
+  "description": "run the atomic update and budget checks, then roll back; requires expected_revision, idempotency_key and reason",
+  "type": "boolean"
+}
    • addedInput schema / properties / reason
      Added value: +{
+  "description": "audit reason required for related updates or preview",
+  "type": "string"
+}
    • addedInput schema / properties / related_updates
      Added value: +{
+  "description": "additional owner-controlled replacements committed together; every item requires memory_id and expected_revision; accepts body, kind, injection_policy, priority, audience and atom_id",
+  "items": {
+    "required": [
+      "memory_id",
+      "expected_revision"
+    ],
+    "type": "object"
+  },
+  "maxItems": 19,
+  "type": "array"
+}
  2. Changed3 schema fields changedv0.7.12
    • changedInput schema / properties / kind / description
      Previous value: -"new kind"New value: +"replacement kind; omit to preserve current kind"
    • addedInput schema / properties / kind / enum
      Added value: +[
+  "preference",
+  "fact",
+  "project",
+  "procedure",
+  "episode",
+  "correction"
+]
    • removedInput schema / properties / status
      Removed value: -{
-  "description": "new status",
-  "type": "string"
-}
  3. First observedv0.7.8

TDQS

A4.5/5.0
Behavior4/5

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

Annotations declare non-readonly, non-destructive, non-idempotent, closed-world, so the safety bar is partially met. The description adds real context beyond them: related_updates commits linked replacements atomically, preview runs checks and rolls back without committing, and the audit reason is required. It stops short of stating irreversibility or revision-bump behavior after a successful commit.

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-loads the trigger condition, then the atomic/preview mechanics, then closes with explicit exclusions. Every sentence carries information, though the middle sentence packs three distinct behaviors (atomic linked updates, required revision/reason/key, preview rollback) densely enough to slow parsing.

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?

For a 13-parameter mutation tool with no output schema, the description covers purpose, atomicity, dry-run semantics, prerequisites and exclusions. Remaining gaps — post-commit revision behavior and what happens to unmentioned fields — are secondary given the schema documents each parameter fully.

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 relational meaning the schema cannot: expected_revision, reason and the retry key are what make related_updates atomic, and preview's prerequisites are tied to that same set. That is meaningful cross-parameter guidance rather than restatement.

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 and resource ('correct body, kind, recall policy, or priority of one known memory') and explicitly contrasts with siblings: not for creating records, changing lifecycle status, or touching another owner's memory. An agent can route between this, memory_write, and memory_status 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 Guidelines5/5

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

Gives explicit when-to-use ('owner must correct...'), when-not ('Do not use to create a record, change lifecycle status, or modify another owner's memory'), and names the mechanism for bulk edits (related_updates) and dry-run (preview). It also states a fallback condition — this recovery entrance works when bootstrap is blocked — which is genuine routing guidance.

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