Skip to main content
Glama

Read history

read_history
Read-only

Read recent repository history entries, search them semantically, or open one entry in full to review past work and decisions.

Instructions

Read recent history entries, search them, or read one entry whole.

- Without ``query``: up to ``limit`` newest entries; ``since`` (ISO8601
  prefix) keeps entries at or after it.
- With ``query``: the semantically nearest entries with cosine distance;
  the index is built on first use and rebuilt when history.md or the
  embedding configuration changes.
- ``offset`` skips that many of the newest (or nearest) entries first.
- With ``entry_id``: that entry with its full text, also an archived one;
  the other arguments are ignored.

A listing stays under Claude Code's 50,000-character result limit: outcome
up to 600 characters, intent and action up to 300, files and tags up to 20
items, and ``truncated`` gives a shortened entry's full lengths. If that is
still too long, previews shrink and the last entries are left out
(``omitted``; ``instruction`` says how to read them).

With user library sync, the entries the user's machines shared for this
repository are merged in, one per entry hash; ``machine`` keeps one
machine label's entries, or ``local`` this checkout's own.

Without a project, it reads the installation's fallback journal (#292):
the entries kept for the same claimed directory, ``query`` as a text match.

Returns JSON: {entries, total, mode, omitted?, instruction?, workspace,
pid, history_last_error?}; mode is recency, semantic or entry. Entries
(machine: null for this checkout's own):
- recency and entry: {id, timestamp, intent, action, outcome, files, tags, metadata, machine}.
- semantic: {id, distance, timestamp, intent, action, outcome, tags, machine}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNoOptional text to search the history for.
sinceNoOptional ISO8601 prefix; only entries at or after it.
offsetNoEntries to skip first, newest or nearest first.
machineNoOptional machine label, or `local` for this checkout's own entries.
entry_idNoOptional id of one entry to return whole; the other arguments are then ignored.
workspaceNoAbsolute path of your working directory, the project this session works in. Pass it whenever you have one: one server can serve several sessions.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv26.10.14+1807

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries real behavioral burden and delivers: it discloses index build/rebuild triggers, the 50,000-character budget with per-field truncation caps, the 'truncated'/'omitted' escape hatches, machine-sync merge semantics (one per entry hash), and the no-project fallback journal. That is far beyond what the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The mode-by-mode bullets are well front-loaded and mostly earn their place, but the entire closing section restates the return payload ({entries, total, mode, omitted?, instruction?, workspace, pid, history_last_error?} plus per-mode entry fields) even though an output schema exists, making it redundant bulk.

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 7-parameter read tool with subtle truncation, index, and sync behavior, the description covers every mode, the fallback path without a project, and the sync/merge rules. Since an output schema exists, the only redundancy is the return-value restatement, not a gap.

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 already 86%, so the baseline is 3, but the description adds real semantics: limit applies to newest entries, since is an ISO8601 prefix and inclusive, offset skips newest-or-nearest, and entry_id suppresses all other arguments. It also explains the machine label versus 'local' distinction beyond the schema's phrasing.

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 first sentence names a specific verb and resource ('Read recent history entries') and immediately enumerates the three distinct modes (list, semantic search, single-entry read). No sibling tool covers history reads, so the tool is unambiguously distinguishable. An agent knows exactly what this does from the opening line.

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?

The bulleted structure gives explicit conditional guidance for each argument: no query means recency listing, query means semantic nearest, entry_id means whole entry with other args ignored. This is strong when-to-use coverage, though it never names an alternative tool or states a when-not-to-use condition, which keeps it below a 5.

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