Skip to main content
Glama

memory_supersede

Explicitly replace an existing memory with a new version by providing the old memory's full ID. The old entry remains in history but is hidden from default search.

Instructions

Explicitly supersede an existing memory with a new one. Use this to record an intentional update — 'this fact replaces that specific memory' — when you know the old memory's id. Unlike memory_write's automatic contradiction detection (a cosine + title heuristic that may link the wrong prior memory or none at all), this targets the given old_id deterministically. Non-destructive: the old memory is retained, its validity interval is closed (is_deleted=1, valid_to set), and a 'supersedes' edge is recorded new -> old. The old memory stays retrievable by id and via memory_history, and as_of-filtered search still sees it valid before the supersession point — it is only dropped from default search. Fields you omit (type, title, importance, scope) are inherited from the old memory, so pass only what changed. To hard-delete instead, that is a separate gated tool (memory_delete). old_id MUST be the full UUID — a prefix is rejected (full UUID required for mutation safety; memory_get accepts a prefix, this does not). Note: each supersede creates a NEW successor memory; call it once with the full id, do not chain supersedes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNo
embedNo
scopeNo
titleNo
old_idYes
sourceNoagent
contentYes
timeoutNo
user_idNo
variantNo
agent_idNo
databaseNo
metadataNo{}
model_idNo
embed_textNo
importanceNo
valid_fromNo
change_agentNo
Behavior4/5

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

With no annotations, the description bears full burden. It discloses key behaviors: non-destructive operation, retention of old memory, closure of validity interval, recording of 'supersedes' edge, inheritance of omitted fields, requirement for full UUID, and prohibition of chaining. However, it does not explain the many other parameters (e.g., embed, timeout, user_id, etc.) and their effects, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is detailed but somewhat lengthy, covering multiple aspects. It is front-loaded with purpose and usage, then behavioral details and parameter notes. While informative, it could be more concise by reducing redundancy (e.g., repeating 'non-destructive' and 'full UUID' points). Still, it is well-structured and readable.

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

Completeness3/5

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

Given the tool's complexity (18 parameters, no output schema, no annotations), the description explains the core functionality well but leaves many parameters (embed, timeout, source, etc.) unexplained. An agent may struggle to use these parameters correctly without additional information. The description is incomplete for fully autonomous use.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It explains only a few parameters: old_id (full UUID required), content (required), and mentions type, title, importance, scope as inheritable. The other 13 parameters (embed, source, timeout, user_id, etc.) are not described, leaving the agent without guidance for their purpose or usage. This is insufficient for a schema with 18 parameters.

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 the tool's purpose: to explicitly supersede an existing memory with a new one. It contrasts with memory_write's automatic detection, provides specifics on the operation (non-destructive, validity interval closed, supersedes edge), and distinguishes from a hard-delete tool. This is specific and helps differentiate from siblings.

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?

The description explicitly explains when to use this tool: when the old memory's ID is known and an intentional update is needed. It contrasts with memory_write's automatic detection, advising against using this tool when that automatic linking is sufficient. It also warns not to chain supersedes. This provides clear guidance on usage vs. alternatives.

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/skynetcmd/m3-memory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server