Skip to main content
Glama
0Mattias

bettermemory

by 0Mattias
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

memory_update

Update an existing memory in place to correct a stored fact, preserving its ID, creation date, and source. Avoids delete-and-recreate when refining what an agent remembers.

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. A transient-state body returns transient_warning; acknowledge_transient=True overrides. 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_transientNo
acknowledge_credentialNo
acknowledge_truncationNo
acknowledge_user_claimNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Tool Definition Quality

A5/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral transparency and does so thoroughly. It discloses side effects (clearing last_verified_at and claims), replace semantics for scopes/links, warning triggers and acknowledgment flags, and the stale-status retry behavior. This is rich, non-obvious information beyond the schema.

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 long but appropriately sized for the tool's complexity. It front-loads the most impactful side effect first, then moves from purpose to parameters to return behavior, using clear section separators. It closes with 'docs/api.md carries the rest' to avoid unnecessary bloat.

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?

Given the 10-parameter complexity and no annotations, the description is remarkably complete. It covers all parameters, warnings, concurrency behavior, link type definitions, and even the stale return condition. With an output schema available for return structure, no critical information is missing for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides zero descriptions for its 10 parameters, so the description must and does fully compensate. It explains each parameter's role, allowed values (e.g., confidence low/medium/high), special constraints (user-inference rejected), array replace semantics, and the meaning of each acknowledgment flag.

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, and explicitly positions it as the preferred alternative to memory_remove + memory_write when correcting a stored fact. This distinguishes it from siblings and makes its purpose unambiguous.

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?

It explicitly recommends using this tool over memory_remove + memory_write for corrections, explains what it preserves, and includes a concrete exclusion: 'user-inference is REJECTED here' because updates lack the write flow's pending-confirm gate. It also advises calling memory_verify after body edits, offering clear when-to-use guidance.

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