Skip to main content
Glama

Source Library

by io.github.Embassy-of-the-Free-Mind
OverviewDiscussionsAdmin

Start a Review Shift

start_review_shift
Read-only

Start a volunteer REVIEW SHIFT: the user lends their Claude (you) to Source Library to check one book, page by page, against its scans. Use when the user wants to help Source Library, says "start a shift" or "review pages", or asks how they can contribute. The user does NOT need to read the book's language: YOU do the checking (scan against transcription, transcription against English) and the user starts the shift, chooses how many pages, watches and asks questions. Returns ONE page: its scan (inline image), our transcription, our English, the last lines of the previous page, and next (pass to continue_review_shift). Follow first_time once, then how_to_run on every page, working through the stretch of pages without stopping between them. With no book, it resumes the user's last run (pass volunteer_code) or picks a book that needs checking; book takes an id, slug or reader URL if the user names one; new_book true skips the resume. Run shifts only while the user is in this conversation; never set one up to run on a schedule or from a script.

Input Schema

NameRequiredDescriptionDefault
bookNoA book the user wants to check: id, slug or sourcelibrary.org reader URL (optional).
languageNoPrefer books in this original language, e.g. "Latin" (optional; any language works, the user need not read it).
new_bookNoTrue to start a different book instead of resuming the last one.
volunteer_codeNoThe code from the user's earlier shift, if they have one. Omit on a first shift; one is issued.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / book
      Added value: +{
+  "description": "A book the user wants to check: id, slug or sourcelibrary.org reader URL (optional).",
+  "type": "string"
+}
    • changedInput schema / properties / language / description
      Previous value: -"Original language the user reads, e.g. \"Latin\", \"Greek\", \"Arabic\", \"German\", \"Chinese\", \"Tibetan\". Omit to accept any language, but ask the user first which languages they read."New value: +"Prefer books in this original language, e.g. \"Latin\" (optional; any language works, the user need not read it)."
    • addedInput schema / properties / new_book
      Added value: +{
+  "description": "True to start a different book instead of resuming the last one.",
+  "type": "boolean"
+}
    • removedInput schema / properties / pages
      Removed value: -{
-  "description": "How many pages (1-5, default 5).",
-  "type": "number"
-}
  2. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds context the annotations cannot: the exact return payload (inline scan image, transcription, English, previous-page tail, next handoff), the session-only constraint, and the resume-vs-fresh behavior via volunteer_code or new_book. It stops short of stating error/failure behavior or what happens if the conversation ends mid-shift, so not a full 5.

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?

Purpose is front-loaded in the first clause, and the remaining sentences are dense but each carries load-bearing information (return shape, handoff protocol, resume logic, session restriction). It is long for a single paragraph and blends orchestration instructions into the description, which is a mild structure cost, but there is little dead text.

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?

Absent an output schema, the description compensates by describing exactly what one call returns and how it chains to continue_review_shift. All four optional parameters and the zero-required-param invocation are addressed. It is nearly complete for a complex orchestration tool; only failure modes and shift termination are unaddressed.

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 3 applies, but the description adds inter-parameter semantics the schema lacks: no book means resume the last run or auto-pick a book needing checking, new_book skips the resume, and volunteer_code is only omitted on a first shift. book's accepted formats (id, slug, reader URL) are echoed from the schema, which is the only redundant sentence.

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?

States a specific verb and resource ('Start a volunteer REVIEW SHIFT') and immediately explains the mechanism: the user lends their Claude to check one book, page by page, against its scans. It explicitly separates itself from continue_review_shift ('next (pass to continue_review_shift)'), so an agent can distinguish it from its closest sibling without opening either schema.

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?

Gives explicit triggers ('wants to help Source Library', 'start a shift', 'review pages', 'asks how they can contribute') and explicit exclusions ('Run shifts only while the user is in this conversation; never set one up to run on a schedule or from a script'). It also routes the follow-up work to the sibling tool, so the when-to-use / when-to-hand-off boundary is fully drawn.

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

All Source Library toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources