Skip to main content
Glama
wusaki0723

Aelios

by wusaki0723
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

memory_archive

DestructiveIdempotent

Soft-archive a memory to remove it from search and recall while keeping the record in storage. Use when the memory might be needed later.

Instructions

Soft-archive a memory: sets status='archived' and removes it from search and recall, but keeps the record in storage (memory_list with status='archived' still shows it). There is no MCP tool to un-archive. Does not touch the supersede chain. Prefer this over memory_delete when the memory might be needed later. Returns { data: { id, archived: true } }, or an error result 'Memory not found'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesMemory id (e.g. from memory_search, memory_recall or memory_list).
namespaceNoMemory space to use. Defaults to 'default'. Ignored when the API key is bound to a fixed namespace.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.2
    • addedInput schema / properties / id / description
      Added value: +"Memory id (e.g. from memory_search, memory_recall or memory_list)."
    • 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."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare destructiveHint=true/idempotentHint=true; the description goes well beyond by specifying exactly what is and isn't affected (removed from search/recall, retained in storage and visible via memory_list with status='archived', supersede chain untouched), that un-archiving is impossible, and the exact success and error return shapes. This is unusually rich behavioral disclosure.

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?

Front-loaded with the core action and its effect, then consequence, then alternative-tool guidance, then return shape. Every sentence carries distinct, decision-relevant information with 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?

For a 2-param mutation tool with no output schema, the description covers effect, irreversibility, persistence behavior, alternative selection, and return/error values. Nothing needed to invoke it correctly is missing.

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% and both parameters (id, namespace) are already documented with examples and defaults in the schema, so the description adds no parameter-level meaning. Baseline 3 applies since the schema does the heavy lifting.

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 ('Soft-archive a memory') and immediately defines the semantics: status becomes 'archived', it disappears from search/recall, but the record persists. It also explicitly contrasts itself with the sibling memory_delete, so an agent can differentiate without opening schemas.

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?

Gives explicit routing guidance: 'Prefer this over memory_delete when the memory might be needed later,' and notes there is no MCP tool to un-archive, which is a decisive constraint for choosing this tool. Both the when-to-use and the irreversible consequence are stated.

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