mcp-automem

Update Memory

update_memory

Idempotent

Update an existing memory's content, tags, importance, or metadata. Use this to correct or enhance memories rather than storing 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" })

Input Schema

Name	Required	Description
`tags`	No	New tags (replaces existing)
`type`	No	Memory type classification
`content`	No	New content (replaces existing)
`t_valid`	No	ISO 8601 timestamp when the memory becomes valid
`metadata`	No	New metadata (merged with existing)
`memory_id`	Yes	ID of the memory to update (from store_memory or recall results)
`t_invalid`	No	ISO 8601 timestamp when the memory expires or was superseded
`timestamp`	No	Override creation timestamp
`confidence`	No	Confidence score for the memory
`importance`	No	New importance score
`updated_at`	No	Explicit update timestamp
`last_accessed`	No	Last access timestamp

Output Schema

Name	Required	Description	Default
`message`	Yes	Confirmation message
`memory_id`	Yes	ID of the updated memory

Schema Changelog

Changes observed during successful MCP inspections.

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

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds the useful 'correct rather than duplicate' angle but doesn't say what happens if memory_id doesn't exist, whether omitted fields are preserved, or how content replacement interacts with history. Nothing contradicts the annotations.

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?

The core purpose is front-loaded in the first sentence, and the 'When to use' list follows logically. The three example calls are helpful but occupy a third of the text and largely restate what the schema properties already say.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 12 parameters, an output schema, and full annotations, the description needs to carry mostly intent and routing, which it does. The remaining gap is behavioral edge cases (missing memory_id, partial-update semantics), which the rich schema partially covers.

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 100%, so every one of the 12 parameters is already documented, and the schema even states replace-vs-merge semantics for tags, content, and metadata. The description names only four fields and its examples show invocation shape rather than adding meaning beyond the schema.

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?

States a specific verb and resource: updating an existing memory's content, tags, importance, or metadata. It also explicitly distinguishes itself from the sibling store_memory by saying to use this 'rather than storing duplicates,' so an agent can route correctly without opening either schema.

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 'When to use' block gives four concrete situations (correction, missing tags, importance adjustment, post-hoc metadata) and rules out the duplicate-store path. It stops short of naming delete_memory or store_memory explicitly as the alternative to pick for other cases, leaving a small gap.

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

Deploy Server