PseudoLife-MCP

Official

Overview Schema Source Related Servers Discussions Admin

memory_supersede

Correct stale memories by storing a replacement and flagging the old entry, so future retrieval favors the new fact and presents both together.

Instructions

Mark a stored memory obsolete and record its replacement. The old entry is kept but flagged superseded, so retrieval ranks the correction higher and shows both together.

Returns: {superseded_count, superseded_texts, new_memory_stored, derived_flagged} — the last being the canonical facts the dream built on the memories just corrected. They are FLAGGED, never rewritten; check each and re-assert the ones that moved. Each row carries has_current_value: false means the slot holds no current fact any more — blast radius worth seeing, but nothing to go re-check. The list is capped, live slots first; derived_flagged_truncated / derived_flagged_total say when a correction reached further than the cap.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`new_text`	Yes	The replacement claim; stored fresh.
`old_text`	Yes	The memory now obsolete. Matched exact-text first, then by nearest embedding — a close paraphrase works.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.15.0Sep 3, 2026

addedInput schema / properties / new_text / description

Added value: +"The replacement claim; stored fresh."

addedInput schema / properties / old_text / description

Added value: +"The memory now obsolete. Matched exact-text first, then by nearest embedding — a close paraphrase works."

First observedv0.11.0Jul 31, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full disclosure burden and does so thoroughly. It reveals that the old entry is kept, not deleted; that derived facts are flagged and never rewritten; that rows carry has_current_value; and that results are capped with truncation indicators.

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 action, then provides dense but purposeful detail about return semantics. Every sentence adds useful information about behavior, flagging, or truncation; there is no 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?

Given the tool's complexity, the description is remarkably complete: it covers matching behavior via the schema, old-entry retention, derived-flag semantics, has_current_value meaning, and truncation reporting. An agent has enough context to invoke this correctly and interpret its result.

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 description coverage is 100%, so the parameters old_text and new_text are already fully documented in the schema. The tool description itself adds no parameter-specific meaning, so the baseline of 3 applies.

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 opens with a specific verb and resource: 'Mark a stored memory obsolete and record its replacement.' It clearly distinguishes supersede from siblings like memory_forget or memory_store by explaining the old entry is kept but flagged, and retrieval ranks the correction higher.

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 description makes the usage context clear: use this when an existing memory is obsolete and a replacement should be recorded, with the old entry preserved for context. It does not explicitly name alternatives or when-not-to-use conditions, so it stops short of a 5.

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