Skip to main content
Glama

ReadingRate

Change a book's status

update_book_status
DestructiveIdempotent

Moves a book that is already in the reader's ReadingRate library to another status: "reading" (sets the start date if there is none), "read" (sets the finish date, with an optional rating), "stopped", or "want_to_read" (clears the finish date). It replaces the book's current status, and for "read" its rating and finish date. Marking a book read also adds it to the reader's ReadingRate activity feed. Other readers see that they finished it while the reader's profile is public and shows finished books (new accounts start private, and finished books start hidden): on the profile, and for people who follow the reader in their feed and on the book's page.

Use when the user says they started, finished, stopped or gave up a book in their library, wants to rate a finished book, or wants a book back on their want-to-read list. For a book not yet in their library, use add_book_to_library.

Examples:

  • {"book_id": "", "status": "reading"}

  • {"book_id": "", "status": "read", "rating": 5}

Input Schema

NameRequiredDescriptionDefault
ratingNoRating from 1 to 5, only with status "read"
statusYesThe new status
book_idYesThe book's ReadingRate id or its library entry id
date_finishedNoFinish date, YYYY-MM-DD, only with status "read" (default: today)

Output Schema

NameRequiredDescriptionDefault
bookNoThe book: id, slug, title, authors
ratingNoThe rating recorded, when finishing
messageYesHuman-readable result
successYesWhether the status changed
new_statusNoThe status after the change
old_statusNoThe status before the change
date_startedNoStart date, when the status is reading
date_finishedNoFinish date, when the status is read

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Despite annotations already flagging destructiveHint=true and idempotentHint=true, the description adds real substance: what gets replaced (current status, and for 'read' the rating and finish date), that 'want_to_read' clears the finish date, and the activity-feed/profile-visibility consequences of marking a book read. It doesn't state auth requirements, but for a mutation with full annotation coverage this is well above the bar.

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?

Structure is strong: purpose and per-status effects first, then usage triggers and the alternative, then examples. The profile-visibility paragraph is dense and runs long relative to its weight, which trims a point, but nothing is truly redundant.

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 destructive mutation with an output schema present, the description covers what changes, what is overwritten, conditional parameter behavior, downstream visibility effects, and routing to the sibling tool. An agent could call this correctly without further information.

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%, so baseline is 3; the description earns above that by explaining the conditional semantics the schema only hints at – 'reading' sets a start date if none exists, 'read' sets finish date plus optional rating, 'want_to_read' clears the finish date. It doesn't clarify the book_id dual-id nuance beyond the schema, keeping it from a 5.

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 opening sentence names a specific verb (moves) and resource (a book already in the reader's library), enumerates all four target statuses, and spells out the per-status side effects (start date, finish date, clearing finish date). It is unambiguously separable from add_book_to_library, which is named explicitly for the out-of-library case.

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?

The second paragraph gives concrete trigger phrases (started, finished, stopped, gave up, wants to rate, back on want-to-read) and names the alternative tool plus the condition that selects it (book not yet in library). Both the when-to-use and the when-not-to-use cases are covered.

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.