Skip to main content
Glama

memory_read

Reads local Markdown/JSONL memory files (default FACT.md), returning full content or a targeted line range via tail, offset, and limit to retrieve only needed memory.

Instructions

读取记忆文件。filename 默认 FACT.md;可传 SOUL.md / USER.md / JOURNAL.jsonl / FACT.archive.md(归档)。三种取法(按优先级):tail>0 只返回最后 tail 行;offset>0 或 limit>0 按行号读一段(offset 从 1 起,limit 最多几行;配合 memory_search 给的行号读归档最省 token);都不给就整份返回。

Input Schema

NameRequiredDescriptionDefault
tailNo
limitNo
offsetNo
filenameNoFACT.md

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.1
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 0,
      +  "title": "Limit",
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "title": "Offset",
      +  "type": "integer"
      +}
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose useful behavior: the default filename, that FACT.archive.md is the archived copy, the precedence rule between tail and offset/limit, and the token-cost trade-off of line-based reads. Gaps remain: it doesn't say what happens when the file doesn't exist or the filename is invalid, and no permissions/rate-limit 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?

Front-loaded with the verb and resource, then the mode selection logic; every clause adds information (defaults, allowed values, precedence, token saving). No filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is not required, and the description plus schema cover invocation completely for a read-only tool. The only real omission is error behavior for missing/invalid filenames, which is minor given the tool's simplicity.

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 description coverage is 0%, so the description must compensate fully, and it does: filename default and allowed values, tail semantics ('last tail lines'), offset's 1-based origin, limit's max-lines meaning, the tail>offset>limit precedence, and the fallback to a full read when none are given. All four parameters get meaning that the bare schema lacks.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states the specific action and resource ('读取记忆文件'), and the description enumerates which files can be read (FACT.md default, plus SOUL.md / USER.md / JOURNAL.jsonl / FACT.archive.md). It also names memory_search as a companion tool, which helps separate it from that sibling. What's missing is a one-line statement of what distinguishes memory_read from memory_search or memory_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It spells out a priority order for the three retrieval modes: tail vs offset/limit vs full read, and explicitly recommends using line numbers from memory_search to read the archive cheaply. That is concrete when-to-use guidance. It doesn't explicitly state when NOT to use this tool (e.g. 'use memory_search to find content instead of reading whole files').

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