Skip to main content
Glama
docmancer

docmancer

Official
by docmancer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

trash_memory

Destructive

Move a memory file to trash so it stops being read or recalled, and get a restore token to undo the action if needed.

Instructions

DESTRUCTIVE BUT REVERSIBLE: move one curated memory file to trash so it stops being read or recalled. Writes to local disk and appends to the change timeline. Nothing is erased: the call returns a restore_token that restore_memory consumes to bring the file back, so keep that token in your reply if the user might change their mind. Guarded by expected_hash, so a stale hash fails without trashing anything. Prefer setting status='archived' with write_memory when the file should stay readable but stop being recalled. Parameters: address identifies the file to trash; expected_hash is its current content_hash from read_memory, confirming you are discarding the revision you actually saw; project_path project root whose memory tree the operation applies to. Omit it to use the machine-wide tree, and always omit it when this server was started pinned to a project. Returns an object with the trashed address and the restore_token needed to undo it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressYesStable docmancer://memory/<id> address, relative path, or exact title of the memory file.
project_pathNoProject root whose memory tree the operation applies to. Omit it to use the machine-wide tree, and always omit it when this server was started pinned to a project.
expected_hashYesThe file's current content_hash from a prior read_memory call. A stale value fails safely instead of overwriting a newer revision.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.9.13
    • addedInput schema / properties / address / description
      Added value: +"Stable docmancer://memory/<id> address, relative path, or exact title of the memory file."
    • addedInput schema / properties / expected_hash / description
      Added value: +"The file's current content_hash from a prior read_memory call. A stale value fails safely instead of overwriting a newer revision."
    • addedInput schema / properties / project_path / description
      Added value: +"Project root whose memory tree the operation applies to. Omit it to use the machine-wide tree, and always omit it when this server was started pinned to a project."
  2. First observedv0.1.0

TDQS

A4.9/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 reversibility, the restore_token mechanism, disk writes, timeline appends, and the safe-failure behavior on stale hashes. It also explains that nothing is erased, which is critical for a destructive operation.

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 dense but each clause adds a distinct fact: identity, effect, guard, return value, and alternative. The most critical warning (reversible/destructive) is front-loaded, and there is no filler or repetition of schema fields.

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 no output schema, the description fully specifies the return shape (address + restore_token) and the failure condition (stale hash). It also covers the write side effects and the conditional project_path behavior, making it self-sufficient for a destructive operation.

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 already covers all three parameters, but the description enriches them: expected_hash is tied to a prior read_memory call and stale-failure semantics, project_path's omit-when-pinned rule is explicit, and address aliases are contextualized. The description adds meaning beyond the schema's basic type info.

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 clear verb-object-effect: 'move one curated memory file to trash so it stops being read or recalled.' It differentiates from siblings by explicitly naming restore_memory and write_memory as alternatives, making the tool's unique role unmistakable.

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 prefer write_memory's status='archived' instead of trashing, and frames conditions for omitting project_path when pinned to a project. The expected_hash guard is presented as a safety precondition, providing concrete guidance for correct usage.

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