Skip to main content
Glama

ReadingRate

Log a reading session

log_reading_session
Destructive

Logs reading for a book in the reader's ReadingRate library: pages read, the page they reached, or a note. It sets the book's current page, adds the pages to today's entry in their reading journal, and adds the note to that entry. One journal entry per book per day: a second call the same day extends that day's pages and appends the note. A book on the want-to-read list moves to reading.

Use when the user says how many pages they read, which page they are on, or wants a thought about today's reading saved with it. For a book not yet in their library, use add_book_to_library first.

Give pages_read (pages read since the last log), current_page (the arabic page reached) or roman_page (a page of an introduction or preface numbered in roman numerals), only one of them; a note can be sent alone. Each call logs again, so do not repeat a call that succeeded.

Introductions numbered i, ii, iii… count. When the reader says their copy's introduction runs to a roman page (for example lx), send front_matter_ends_on with it, alone or with the page; the copy keeps it, and later arabic pages count after it. "0" means the copy has none, or the reader skipped it, which takes its pages back out.

Examples:

  • {"book_id": "", "pages_read": 30}

  • {"book_id": "", "current_page": 150}

  • {"book_id": "", "front_matter_ends_on": "lx", "roman_page": "liv"}

  • {"book_id": "", "notes": "The argument only lands once you have read the footnotes."}

Input Schema

NameRequiredDescriptionDefault
notesNoThe reader's note on today's reading, added to today's journal entry
book_idYesThe book's ReadingRate id or its library entry id
pages_readNoPages read in this session, added to the current page
roman_pageNoThe page the reader is now on in the book's roman-numbered introduction or preface, such as "liv"
current_pageNoThe page the reader is now on, as printed in arabic numerals
front_matter_ends_onNoThe last roman-numbered page of the reader's copy, such as "lx" (or 60); "0" when it has none or they skipped it

Output Schema

NameRequiredDescriptionDefault
bookNoThe book: id, slug, title, authors
messageYesHuman-readable result
successYesWhether the session was logged
estimateNohours_remaining and description; null when the total pages are unknown
progressNocurrent_page (the stored position, counted from page i when the copy has roman front matter), page_label (the page as the book prints it, e.g. "liv" or "10"), front_matter_pages, total_pages (printed pages of the reader's copy, without a roman introduction: show page_label of total_pages), percent_complete and pages_remaining (over the whole copy)
velocity_usedNoPages per hour used for the estimate
status_changedNoSet when the book moved from want-to-read to reading

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses concrete state effects: one journal entry per book per day, second call extends that day's pages and appends notes, want-to-read books transition to reading, and front_matter_ends_on is persisted so later arabic pages count after it. It reinforces the non-idempotent annotation with an explicit caution against repeating successful calls.

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

Conciseness4/5

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

Front-loaded with purpose, then usage, then parameter rules, then compact JSON examples — a sensible ordering. It is dense but nearly every sentence carries a rule; only minor overlap exists between the prose about setting the current page and the parameter descriptions.

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 an output schema present, the description needn't explain return values, and it covers the remaining ground: triggers, prerequisites, mutual exclusivity, roman-numeral edge cases, and duplicate-call risk. Nothing an agent needs to invoke this mutation correctly is missing.

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 the description adds rules the schema does not encode: pages_read/current_page/roman_page are mutually exclusive ('only one of them'), a note may be sent alone, and roman numbering for introductions must be recorded via front_matter_ends_on with special '0' semantics that removes those pages. These are real constraints, not restatements.

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?

Specific verb and resource ('Logs reading for a book in the reader's ReadingRate library') plus a precise enumeration of side effects: sets current page, adds pages to today's journal entry, appends note, and moves want-to-read books to reading. This clearly separates it from siblings like update_book_status or save_reading_insight, which do not log session pages.

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 when the user says how many pages they read, which page they are on, or wants a thought about today's reading saved with it' gives an explicit trigger condition. It also names the prerequisite alternative ('For a book not yet in their library, use add_book_to_library first') and a negative instruction ('do not repeat a call that succeeded').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.