Skip to main content
Glama
docmancer

docmancer

Official
by docmancer
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

read_memory

Read-onlyIdempotent

Read a curated memory file in full by its stable address, relative path, or exact title. Returns content, metadata, and content hash, or ambiguous-match candidates for retry.

Instructions

READ-ONLY: read one curated memory file in full, resolved by stable address, relative path, or exact title. Local disk read with no side effects. Ambiguous title or path matches return every candidate address rather than guessing, so a caller can retry with an exact address. This is also how you obtain the content_hash that edit_memory, move_memory, duplicate_memory, and trash_memory all require. Use search_memory first when you do not already know which file you want. Parameters: address is the docmancer://memory/ address, the relative path, or the exact title; 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 body, frontmatter, address, content_hash, and revision id, or a candidates list when the address was ambiguous.

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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 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 / memory_id
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Memory Id"
-}
    • 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"
+]
  2. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Beyond annotations, it discloses local disk read with no side effects, and the ambiguous-match behavior that returns all candidate addresses instead of guessing. It also states the return shape including candidates list.

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 sentence adds value, starting with 'READ-ONLY' and the core action, then addressing ambiguity, related tools, parameters, and return value. No fluff.

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 covers return values (body, frontmatter, address, content_hash, revision id, or candidates list). It also covers parameter nuances, relationship to sibling tools, and side effects, making it complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds contextual meaning: address can be docmancer URI, relative path, or exact title, and project_path clarifies machine-wide vs. pinned project usage. This exceeds the schema 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 clearly states the tool reads one curated memory file in full, resolved by stable address, relative path, or exact title. It distinguishes itself from sibling tools by explicitly directing to search_memory for unknown targets.

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 advises using search_memory first when the target file is unknown, and notes this tool is the way to obtain content_hash for edit/move/duplicate/trash operations. This gives clear when-to-use and context.

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