Skip to main content
Glama
docmancer

docmancer

Official
by docmancer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

move_memory

Destructive

Move or rename a memory file while preserving its stable docmancer:// address. Requires the current content hash to ensure a safe update.

Instructions

MUTATING and DESTRUCTIVE at the old path: move or rename one curated memory file. Writes to local disk and appends to the change timeline. The file's stable docmancer://memory address survives the move, so existing references by address keep working, but the old relative path stops resolving and anything referring to it by path breaks. Guarded by expected_hash, so a stale hash fails without changing anything. The body is untouched: use edit_memory to change content, or duplicate_memory to copy rather than move. Parameters: address identifies the file to move; new_relative_path is its destination path in the tree, including the .md suffix, and renaming is just a move within the same directory; expected_hash is the file's current content_hash from read_memory; 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 unchanged address, the new path, and the new revision id.

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.
new_relative_pathYesRelative path, including the .md suffix, for the memory file inside its selected memory tree.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed17 schema fields changedv0.9.13
    • removedInput schema / properties / address / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / address / default
      Removed value: -null
    • addedInput schema / properties / address / description
      Added value: +"Stable docmancer://memory/<id> address, relative path, or exact title of the memory file."
    • addedInput schema / properties / address / type
      Added value: +"string"
    • removedInput schema / properties / expected_hash / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / expected_hash / default
      Removed value: -null
    • 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 / expected_hash / type
      Added value: +"string"
    • removedInput schema / properties / hash
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Hash"
-}
    • removedInput schema / properties / new_path
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "New Path"
-}
    • removedInput schema / properties / new_relative_path / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / new_relative_path / default
      Removed value: -null
    • addedInput schema / properties / new_relative_path / description
      Added value: +"Relative path, including the .md suffix, for the memory file inside its selected memory tree."
    • addedInput schema / properties / new_relative_path / type
      Added value: +"string"
    • 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."
    • removedInput schema / properties / target
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Target"
-}
    • addedInput schema / required
      Added value: +[
+  "address",
+  "new_relative_path",
+  "expected_hash"
+]
  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?

Beyond the annotations (destructiveHint=true), the description discloses on-disk writes, timeline appends, address stability, and path breakage. It also explains the expected_hash guard with a safety guarantee: 'a stale hash fails without changing anything.' This is rich, non-obvious behavioral context.

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 every clause earns its place, covering why, how, safety, and relationships to siblings. It is well-structured with a clear flow from action to implications to parameter guidance, and ends with return-value notes.

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?

With no output schema, the description explicitly states the return shape: 'an object with the unchanged address, the new path, and the new revision id.' It also addresses the mutating/destructive nature, safety guard, and all relevant usage contexts, making it fully self-contained.

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%, giving a baseline of 3. The description adds meaningful context to new_relative_path ('renaming is just a move within the same directory') and clarifies the hash's role from read_memory, enhancing the schema's static descriptions.

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 'move or rename one curated memory file', a specific verb and resource. It further distinguishes from siblings by explicitly pointing to edit_memory for content changes and duplicate_memory for copying, so the agent instantly knows which tool to pick.

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?

It clearly states when to use this tool (move/rename) and provides explicit alternatives: 'use edit_memory to change content, or duplicate_memory to copy rather than move.' It also gives practical guidance on project_path usage and omission rules.

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