Skip to main content
Glama

Read what the reader has read

folio_reads
Read-onlyIdempotent

Read the reader's read record to tell whether they have seen a passage or what is new on a page. Returns documents read under a folder, or a document's blocks with the versions read and the marks its page shows.

Instructions

Read the reader's read record. For a folder, or with no path, every document read under it and when it was last read; for a document, each block with the version the reader read and when, and the marks its page shows. Use it to tell whether the reader has seen a passage or what is new to them on a page; for the list of documents changed since read use folio_changes. It reveals the reader's reading. While the reader pauses sharing in Folio, it answers only {paused: true, message}. Answers {documents: [{path, at: ISO time}]} for a folder, or for a document {blocks: [{id, kind, source, lines, version, read: {version, at: ISO time} or null}], marks: [{source, id, mark: new or changed, before and after: the text as read and as it is, data: embeds whose data changed - a mark from data alone has no before or after, at: ISO time, parts: the rows, items or lines marked in a table, list or code block}], removed: [{source, id, text, after and before: the ids it stood between, at: ISO time}], links: [{source, id, url, state: changed or gone}], upstream: [{path, how, at}], version}. A list cut to fit one answer adds omitted, the entries each list left out, and narrow, how to ask for less.

Input Schema

NameRequiredDescriptionDefault
pathNoA document, relative to the served folder or absolute under it, such as notes/plan.md, or a folder ending in /; omit for every document read

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover readOnly/idempotent/non-destructive, but the description adds behavior the annotations cannot express: a paused-sharing mode that returns only {paused: true, message}, per-scope response shapes, and a truncation contract where lists gain omitted and narrow. These are real operational facts an agent must anticipate before calling.

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 opening scope and routing sentences are front-loaded and waste nothing, but the middle sentence is a single ~150-word enumeration of return shapes that is hard to scan and would read far better as a short structured list. Since there is no output schema some of this length is earned, but the presentation costs clarity.

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 carries the full burden of return-value documentation and does so: documents, blocks with version/read, marks with before/after and parts, removed, links, upstream, version, plus the truncation fields and the paused case. Nothing an agent needs to interpret or safely call this read-only tool is missing.

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% and the single path parameter is already documented, so the schema does most of the work. The description still adds meaning by tying the parameter choice to different result scopes (folder or no path yields documents; a document yields blocks and marks), which is more than restating the schema.

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?

"Read the reader's read record" gives a specific verb and resource, then immediately splits the two behaviors: folder/no-path returns every document read and when, document returns per-block read versions plus page marks. It also explicitly names the sibling it is not (folio_changes) for the changed-since-read list, so an agent can route without opening schemas.

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?

"Use it to tell whether the reader has seen a passage or what is new to them on a page" states the decision condition positively, and "for the list of documents changed since read use folio_changes" names the alternative and the condition that selects it. That is explicit when-to-use and when-not-to-use in one sentence.

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