mcp-automem

Update Memory

update_memory

Idempotent

Update an existing memory's content, tags, importance, or metadata to correct inaccurate information or enhance stored details without creating duplicates.

Instructions

Update an existing memory's content, tags, importance, or metadata. Use this to correct or enhance memories rather than storing duplicates.

When to use:

To correct inaccurate information in a memory
To add tags that were forgotten
To adjust importance based on new understanding
To add metadata after the fact

Examples:

update_memory({ memory_id: "8f3a2c1e-5b7d-4e9a-a1c3-2d4f6b8e0a91", importance: 0.95 }) // Increase importance
update_memory({ memory_id: "8f3a2c1e-5b7d-4e9a-a1c3-2d4f6b8e0a91", tags: ["project-x", "critical", "auth"] }) // Add tags
update_memory({ memory_id: "8f3a2c1e-5b7d-4e9a-a1c3-2d4f6b8e0a91", content: "Updated: PostgreSQL chosen for ACID + team expertise" })

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "memory_id": "<memory_id>"
    },
    "name": "update_memory"
  }
}

Input Schema

Name	Required	Description
`tags`	No	Replaces existing
`type`	No
`content`	No	Replaces existing
`t_valid`	No	ISO 8601 start of validity
`metadata`	No	Replaces the stored metadata object. To change one key, fetch the memory first and send the full object. Omit metadata to preserve it.
`memory_id`	Yes	ID of the memory to update
`t_invalid`	No	ISO 8601 expiry or supersede time
`timestamp`	No	Overrides creation time
`confidence`	No
`importance`	No
`updated_at`	No	ISO 8601
`last_accessed`	No	ISO 8601

Output Schema

Name	Required	Description	Default
`message`	Yes
`memory_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv0.14.4Nov 5, 2026

removedInput schema / properties / confidence / description
```
Removed value: -"Confidence score for the memory"
```

changedInput schema / properties / content / description

Previous value: -"New content (replaces existing)"New value: +"Replaces existing"

removedInput schema / properties / importance / description
```
Removed value: -"New importance score"
```

changedInput schema / properties / last_accessed / description

Previous value: -"Last access timestamp"New value: +"ISO 8601"

changedInput schema / properties / memory_id / description

Previous value: -"ID of the memory to update (from store_memory or recall results)"New value: +"ID of the memory to update"

changedInput schema / properties / metadata / description

Previous value: -"New metadata (merged with existing)"New value: +"Replaces the stored metadata object. To change one key, fetch the memory first and send the full object. Omit metadata to preserve it."

changedInput schema / properties / t_invalid / description

Previous value: -"ISO 8601 timestamp when the memory expires or was superseded"New value: +"ISO 8601 expiry or supersede time"

changedInput schema / properties / t_valid / description

Previous value: -"ISO 8601 timestamp when the memory becomes valid"New value: +"ISO 8601 start of validity"

changedInput schema / properties / tags / description

Previous value: -"New tags (replaces existing)"New value: +"Replaces existing"

changedInput schema / properties / timestamp / description

Previous value: -"Override creation timestamp"New value: +"Overrides creation time"

removedInput schema / properties / type / description
```
Removed value: -"Memory type classification"
```

changedInput schema / properties / updated_at / description

Previous value: -"Explicit update timestamp"New value: +"ISO 8601"

removedOutput schema / properties / memory_id / description
```
Removed value: -"ID of the updated memory"
```
removedOutput schema / properties / message / description
```
Removed value: -"Confirmation message"
```

Changed2 schema fields changedv0.14.1Jun 28, 2026

addedInput schema / properties / t_invalid

Added value: +{
+  "description": "ISO 8601 timestamp when the memory expires or was superseded",
+  "type": "string"
+}

addedInput schema / properties / t_valid

Added value: +{
+  "description": "ISO 8601 timestamp when the memory becomes valid",
+  "type": "string"
+}

First observedv0.14.0May 26, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), so the description's added behavioral value is limited to the "correct rather than duplicate" rationale. It does not state that omitted fields are preserved or that tags/content are replaced wholesale, even though that replacement behavior is the most consequential trait for a mutation call.

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?

Strong front-loading: the core purpose appears in the first sentence, followed by use cases and then examples. The three examples repeat the same full UUID verbatim, which is avoidable bulk, but nothing is genuinely redundant with the schema.

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?

For a 12-parameter mutation tool with an output schema and full annotations, the description supplies intent, scenarios, and worked calls. Return values are covered by the output schema, and the destructive nuances of individual params are handled in the schema text, leaving no significant gap for an agent to call it correctly.

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 75% and the schema itself spells out the replacement semantics ("Replaces existing", metadata must be fetched and resent whole). The examples illustrate memory_id, importance, tags, and content usage, but say nothing about type, confidence, t_valid/t_invalid, or timestamp beyond what the schema documents, so the description adds marginal meaning.

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?

Opens with a specific verb and resource ("Update an existing memory's") and enumerates the mutable facets (content, tags, importance, metadata). The second sentence distinguishes it from store_memory by stating the intent is correction rather than duplicate creation, so the agent can separate the two mutation tools without inspecting schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The explicit "When to use" list covers four concrete scenarios and the examples demonstrate single-field updates. It also implicitly steers away from store_memory, but it never names delete_memory as the alternative for removal, so the exclusions are only partial.

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

Deploy Server