Skip to main content
Glama

memory_supersede

Replace a specific memory by providing its exact UUID. The old memory is retained for historical access, but default search shows only the new successor.

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
user_idNo
variantNo
agent_idNo
databaseNo
metadataNo{}
model_idNo
embed_textNo
importanceNo
valid_fromNo
change_agentNo
Behavior5/5

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

No annotations present, so description fully details behavior: non-destructive action (old memory retained with validity interval closed, edge recorded), field inheritance, and search visibility. This comprehensive transparency compensates for the lack of 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 description is informative but somewhat lengthy. It front-loads purpose and usage, and every sentence adds important context. Could be slightly more streamlined, but it is efficient for the complexity.

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?

Given high complexity (17 params, no output schema, no annotations), the description covers essential behavioral and usage context. It lacks explicit return value information, but for a mutation tool this is acceptable. Overall, it provides sufficient completeness for an agent to use the tool correctly.

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

Parameters4/5

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

Schema coverage is 0%, so description adds value by explaining key parameters (old_id, content, inheritance of omitted fields). However, it does not explicitly describe all 17 parameters, leaving some details to the schema defaults.

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 verb (supersede) and resource (memory), and distinguishes it from siblings like memory_write and memory_delete, making its unique purpose immediately clear.

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?

Explicitly explains when to use this tool vs memory_write (automatic detection may link wrong memory) and mentions memory_delete for hard-deletes. Also provides a critical constraint: old_id must be a full UUID, not a prefix.

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