Skip to main content
Glama

Fix a memory's subject, tags, or metadata

amber_update_memory

Correct a stored memory's subject, topic tags, or metadata after the fact without changing the fact's wording. Fixes mis-attributed or stale memories, including ones in the trash.

Instructions

Correct a stored memory after the fact. Use this when you notice -- e.g. while reviewing search results -- that a memory has the WRONG or MISSING subject (who it's about), a wrong/missing topic tag, or stale metadata. Does NOT change the fact's wording; to reword a fact, delete it and store the corrected version. Works on TRASHED memories too, deliberately: correcting a subject or tag while a memory sits in the trash keeps it coherent for a later restore -- the same reason amber_rename_subject relabels trashed records.

Pass memory_id plus only the fields you want to change:

  • subject: who the memory is about, e.g. "patrick" or "patrick's father". Fixes mis-attributed facts (e.g. a fact about the user's dad wrongly tagged as the user). It REPLACES every subject, so subject: "" removes them all.

  • rederive_subject: true to re-extract the subject from the memory's own content (use when it's clearly wrong but you don't know the right value). Ignored if subject is given.

  • add_topics / remove_topics: topic/category names to add or remove, e.g. ["health"].

  • add_subjects / remove_subjects: person name(s) to add or remove as co-subjects WITHOUT clobbering the others -- e.g. a fact naming two people that was tagged with only one: add_subjects: ["tjeerd spruijt"]. (Use subject to REPLACE the whole subject set instead.)

  • set_metadata: object of metadata fields to set or overwrite, e.g. { "importance": "high" }.

  • clear_metadata: metadata field names to remove, e.g. ["importance"].

Reuse existing names: subjects are matched by EXACT (case-insensitive) text -- call amber_list_subjects and reuse the stored spelling -- while topics are matched SEMANTICALLY -- call amber_list_topics.

Example -- a fact about the user's father is tagged as the user: amber_update_memory({ memory_id: "...", subject: "patrick's father" }). Returns the updated memory. Requires an active subscription.

Errors: not_found (no memory with that id on this account; a trashed memory is found and updated), invalid_input (a field has the wrong type, nothing to change was supplied, or the change would leave the memory over a store limit: 3 topics, 4000 bytes of metadata).

Input Schema

NameRequiredDescriptionDefault
subjectNoSet who this memory is about, e.g. "patrick" or "patrick's father". Lowercase named subject.
memory_idYesUUID of the memory to update (from search/list results).
add_topicsNoTopic/category names to add as tags (e.g. ["health", "food"]). Matched semantically; call amber_list_topics to reuse existing names.
add_subjectsNoLowercase person name(s) to ADD as co-subjects without clobbering existing ones (e.g. ["tjeerd spruijt"]). Use when a fact names more than one person but was tagged with only some. Matched by exact text; call amber_list_subjects to reuse the stored spelling. Use FULL names: adding a bare first name that merely matches an existing subject can attach this memory to the WRONG person of that name -- if you are not certain who is meant, ask the user first.
set_metadataNoMetadata fields to set or overwrite (e.g. { "source": "chat" }).
remove_topicsNoTopic/category names to remove from this memory.
clear_metadataNoMetadata field names to remove (e.g. ["source"]).
remove_subjectsNoLowercase person name(s) to remove from this memory's subjects.
rederive_subjectNoRe-extract the subject from the memory's content (use when it's wrong but you don't know the correct value). Ignored if `subject` is also given.

Output Schema

NameRequiredDescriptionDefault
memoryYesThe memory as it now stands. Its `content` is unchanged: this tool edits labels, never wording.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.6

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the tool deliberately works on trashed memories, that subject replacement clobbers the whole subject set, that an empty subject removes all subjects, and that rederive_subject is ignored when subject is supplied. It also documents subscription requirements, store limits (3 topics, 4000 bytes of metadata), and not_found/invalid_input error behavior. This goes well beyond what readOnlyHint=false and destructiveHint=false convey.

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 front-loaded with the core purpose and then structured into a clear field-by-field bullet list, followed by matching guidance, an example, and errors. Despite being long, the length is justified by nine parameters and multiple non-obvious semantic distinctions; no sentence is filler.

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?

Everything an agent needs to call this correctly is present: required memory_id, optional fields and their interactions, trashed-memory behavior, matching rules, subscription requirement, limits, and error cases. The output schema covers the return value, so the description does not need to explain the full response shape beyond noting that it returns the updated memory.

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?

Although the schema has full description coverage, the description adds important semantics that are not merely restated: subject REPLACES every subject, add_subjects/remove_subjects modify co-subjects without clobbering, subjects match by exact case-insensitive text while topics match semantically, and set_metadata/clear_metadata operate at field level. It also explains the interaction between subject and rederive_subject and gives a concrete correcting example.

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 states a specific verb and resource: 'Correct a stored memory after the fact' for subject, tag, and metadata fixes. It explicitly excludes rewording facts and names the correct alternative workflow (delete and store the corrected version). It is easy to distinguish from siblings such as amber_rename_subject, amber_store_memory, and amber_delete_memory.

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 says exactly when to use the tool: noticing a wrong or missing subject, tag, or stale metadata, including while reviewing search results. It also gives explicit when-not guidance for rewording a fact and for replacing versus adding subjects. Alternative tools are named for listing subjects and topics before reuse.

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