Skip to main content
Glama

Update memory

update
Idempotent

Update an existing memory by ID. Use mode replace (default) to patch fields, or append to extend content. Re-embeds only when content changes. The target workspace is always the one the memory itself belongs to (echoed in resolved_workspace); optionally pass workspace: as a safety confirmation — the call fails if the memory is not actually in that workspace.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesUUID of the memory to update.
modeNoreplace = patch fields; append = extend content with revision history.replace
tagsNoOptional tags. A tag like project:my-app also sets collection automatically.
typeNoMemory category: general, preference, fact, instruction, or conversation. Omit to include all types.
contentNoNew or appended content.
workspaceNoTo operate on a team workspace, pass its exact name, slug, or ID (e.g. "Acme"). Omit — or pass "personal" — for your personal memory (default). Every response echoes resolved_workspace so you can confirm where the operation actually happened. Call list_collections when unsure of the exact workspace name.
collectionNoScope slug (e.g. project:memxus, personal:preferences). GitHub/Notion connector syncs use project:<slug> — one collection per project. Partial names work; call list_collections when unsure.
importanceNoRelevance weight from 0 to 1.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoTags attached to the memory.
messageYesHuman-readable confirmation.
memory_idYesUUID of the updated memory.
collectionNoCollection slug, or empty string if none.
importanceNoStored importance (0–1).
memory_typeYesStored memory category.
resolved_workspaceNoThe workspace this call actually operated on (defense against writing to the wrong team by typo or name collision). id=null means Personal.

TDQS

A4.9/5.0
Behavior5/5

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

Discloses key behaviors not in annotations: re-embedding only when content changes, workspace safety check, mode-specific behavior (replace vs append with revision history). No contradiction with annotations (readOnlyHint=false, idempotentHint=true).

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?

Single paragraph packs all necessary info without redundancy. Front-loaded with main action. Minor improvement: could use bullets for clarity, but currently efficient.

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 8 parameters and complex behavior, description covers all critical aspects: modes, side effects, safety checks, tag behavior, workspace handling. Output schema exists (not described, per rules fine).

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?

Even with 100% schema coverage, description adds significant value: tag auto-sets collection, append extends with revision history, workspace as safety confirmation, and collection usage guidance. Schema descriptions are adequate but description enriches semantics.

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?

Description explicitly states 'Update an existing memory by ID' with clear resource (memory) and action (update). Distinguishes from siblings like forget (delete), remember (create), get_memory (read). Two modes (replace/append) further specify purpose.

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 explicit when-to-use (updating existing memory) and when-not (calls fail if workspace mismatch). Suggests list_collections for workspace/collection uncertainty. Includes safety confirmation behavior.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: forget deletes, remember saves, update modifies, recall searches, list_memories lists, get_memory retrieves full details, get_context builds a context block, list_collections lists folders, memory_stats shows counts. There is no functional overlap that would confuse an agent.

Naming Consistency3/5

Names mix conventions: forget, recall, remember, update are single verbs; get_context, get_memory, list_collections, list_memories follow verb_noun; memory_stats is noun_noun. This inconsistency can make it harder for an agent to predict tool names.

Tool Count5/5

With 9 tools, the server is well-scoped for a memory management system. Each tool addresses a core operation (CRUD, search, stats, context building) without unnecessary redundancy. The count is appropriate for the domain.

Completeness4/5

The surface covers create (remember), read (list_memories, get_memory, recall, get_context), update (update), delete (forget), plus metadata tools (list_collections, memory_stats). Missing explicit filtering by tags or bulk operations, but these are minor gaps given the semantic search capability.