Skip to main content
Glama
wusaki0723

Aelios

by wusaki0723
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

memory_supersede

Destructive

Replace an outdated memory while preserving its history: mark the old entry as superseded and create a linked active entry when a fact changes over time.

Instructions

Replace an outdated memory while keeping history: marks old_id as superseded (kept, and visible via memory_recall with include_history) and inserts a new active memory linked to it. The new entry inherits the old fact_key unless new_fact_key is given. If old_id does not exist, the new memory is still created and oldStatus is 'missing'. Use it when a fact changed over time; to fix a mistake in place use memory_upsert, and to remove a memory use memory_archive or memory_delete. Returns { data: { oldStatus, newId } }.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
old_idYesId of the memory being replaced.
reasonNoShort note on why the old memory is outdated; stored with the chain.
new_typeNoOne of fact, event, preference, relationship, boundary, habit, decision, note. Other values become fact (default).
namespaceNoMemory space to use. Defaults to 'default'. Ignored when the API key is bound to a fixed namespace.
authored_byNoE-axis signature for the new entry (hand sources only)
new_contentYesThe up-to-date memory text.
valid_as_ofNoWhen the new fact became true (ISO date or datetime).
new_fact_keyNofact_key for the new entry. Defaults to the old entry's fact_key.
response_tendencyNoE-axis: how to respond when the new memory fires

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.1.2
    • addedInput schema / properties / namespace / description
      Added value: +"Memory space to use. Defaults to 'default'. Ignored when the API key is bound to a fixed namespace."
    • addedInput schema / properties / new_content / description
      Added value: +"The up-to-date memory text."
    • addedInput schema / properties / new_fact_key / description
      Added value: +"fact_key for the new entry. Defaults to the old entry's fact_key."
    • addedInput schema / properties / new_type / description
      Added value: +"One of fact, event, preference, relationship, boundary, habit, decision, note. Other values become fact (default)."
    • addedInput schema / properties / old_id / description
      Added value: +"Id of the memory being replaced."
    • addedInput schema / properties / reason / description
      Added value: +"Short note on why the old memory is outdated; stored with the chain."
    • addedInput schema / properties / response_tendency / description
      Added value: +"E-axis: how to respond when the new memory fires"
    • addedInput schema / properties / valid_as_of / description
      Added value: +"When the new fact became true (ISO date or datetime)."
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructiveHint annotation by disclosing the exact mutation mechanics: the old entry is kept and remains visible via memory_recall with include_history, a new active memory is linked to it, and the fact_key is inherited unless overridden. It also documents the edge case that a missing old_id still creates the new memory with oldStatus 'missing'.

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?

Front-loads the core behavior and return shape in a compact sequence of sentences with no filler. Slightly dense at five sentences, but each one carries distinct information (mechanism, edge case, alternatives, return).

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 9-parameter destructive mutation tool, the description covers the operation, its side effects on history, the edge case, sibling routing, and the return shape. Nothing an agent needs to invoke it correctly is missing, even without an output schema.

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 100%, so baseline is 3, but the description adds genuine meaning: new_fact_key defaults to the old entry's fact_key, and old_id's non-existence yields a 'missing' status rather than failure. These behavioral notes exceed what the schema documents.

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+resource ('Replace an outdated memory while keeping history') and immediately contrasts it with the sibling tools memory_upsert, memory_archive, and memory_delete. An agent can distinguish it from all siblings without opening a schema.

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 states when to use it ('when a fact changed over time') and names the alternatives for adjacent scenarios ('to fix a mistake in place use memory_upsert, and to remove a memory use memory_archive or memory_delete'). No inference required.

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

Deploy Server

Other Tools