Skip to main content
Glama
0Mattias
by 0Mattias

memory_update

Update an existing memory in place, preserving its ID and creation time. Correct stored facts without removing the record, with staleness detection if another agent modifies it first.

Instructions

Body edits clear last_verified_at; scope-only edits preserve it. Bundling a scope rename with a body edit clears verification.

Refine an existing memory in place. Preferred over memory_remove + memory_write when correcting a stored fact — preserves id, created, and source; bumps updated.

Parameters (pass at least one):

  • id: required.

  • content: new body. Replacing the body clears last_verified_at, the verified-* attestations, and claims (the prior verification was for prose that no longer exists; call memory_verify again after, re-declaring claims). A body that reads as a claim ABOUT THE USER returns user_claim_warning unless the record is already user-inference; pass acknowledge_user_claim=True if the subject is someone else. An edit that SHRINKS the body and leaves it ending mid-sentence returns truncation_warning; pass acknowledge_truncation=True when the cut is deliberate.

  • scopes / links: REPLACE semantics — pass the full new list, or [] to clear.

  • confidence: low / medium / high.

  • category: accepts fact and ambient. user-inference is REJECTED here — that category exists to gate WRITES through the pending-confirm flow; updates have no equivalent gate.

Returns status="stale" when another agent updated the memory first; the hint says to re-fetch and retry. Each links entry is {type, target_id (a ULID), note?}. The types: supersedes (prefer this over the target), contradicts (both cannot be true), extends (adds nuance to it), depends_on (only makes sense in its context). docs/api.md carries the rest.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
linksNo
scopesNo
contentNo
categoryNo
confidenceNo
acknowledge_credentialNo
acknowledge_truncationNo
acknowledge_user_claimNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Given no annotations, the description carries full behavioral burden. It details side effects like clearing last_verified_at and claims, replace semantics for scopes/links, category restrictions, warnings, and stale status handling, which goes far beyond basic expectations.

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?

The description is dense but well-structured: verification semantics first, then purpose, then parameter details, then return/link info. Every sentence adds meaningful information, and the length is justified by the tool's complexity.

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?

The description covers nearly all essential behavioral aspects including return status, hint, link types, and category restrictions. With an output schema present, not detailing return values further is acceptable. The only minor gap is acknowledge_credential, but overall the description is complete for this complex tool.

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?

The description explains all core parameters in detail (content, scopes/links, confidence, category, id) and mentions acknowledge_truncation and acknowledge_user_claim. However, acknowledge_credential is never mentioned, leaving a small gap in an otherwise comprehensive parameter explanation.

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 clearly states 'Refine an existing memory in place' with a specific verb and resource. It also distinguishes itself from memory_remove + memory_write by noting preservation of id/created/source and preferred usage, which separates it from sibling tools.

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?

Explicitly says 'Preferred over memory_remove + memory_write when correcting a stored fact', giving a clear when-to-use directive. It also mentions calling memory_verify after body edits and rejects user-inference here, implying alternative tool usage for writes.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/0Mattias/bettermemory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server