Skip to main content
Glama
MerakOsiris

MemoryGuard

by MerakOsiris
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

memoryguard_memory_update

Update a known memory's content, category, recall policy, or priority. Use to correct inaccurate memory details without altering lifecycle or ownership.

Instructions

Use when owner must correct body, kind, recall policy, or priority of one known memory. 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
atom_idNoV2 atom ID; use the source-mapping target when a migrated logical ID is ambiguous
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
injection_policyNonew injection policy
agent_instance_idNooptional identity consistency check; trusted MCP environment is authoritative

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
-}
  2. First observedv0.7.8

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already signal a write operation (readOnly=false) and non-idempotence, and the description adds ownership and scope constraints beyond those annotations. However, it does not disclose partial-update behavior, return semantics, or identity-check consequences, so behavioral disclosure is only moderate.

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?

Two tight sentences with no filler: the use condition is front-loaded and each clause carries routing or exclusion information.

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 mutation tool with nine parameters and no output schema, the description supplies the needed selection criteria and exclusions while the schema covers parameter details. It could specify update result/return semantics, but what is needed to choose the tool correctly is present.

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%, so the baseline is 3 and the schema documents all parameters. The description lightly maps 'recall policy' to injection_policy and emphasizes which fields are correctable, but it does not add substantive meaning beyond the schema.

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 action: owner correcting body, kind, recall policy, or priority of one known memory. It clearly distinguishes from memory_write by excluding record creation and from memory_status by excluding lifecycle changes.

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 an explicit when-to-use condition ('Use when owner must correct ... one known memory') and explicit exclusions (not for creating a record, changing lifecycle status, or modifying another owner's memory). This is strong 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