Skip to main content
Glama

Source Library

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

Read Book Text

get_book_text
Read-onlyIdempotent

READ PIPELINE step 2 — READ. Read a book's text. Call get_book first (step 1) for the chapter list, then come here. Preferred: use the chapter param to read one chapter at a time (includes [Page N] markers for citation). Alternatively, use from/to for explicit page ranges (e.g. from=1 to=50). When you find passages worth quoting, hand the page numbers to get_quote / get_quotes (step 3) for verbatim text + a citation link. TRUNCATION: the response always includes truncated: true/false. When truncated=true, the truncation_note field gives the exact next from/to values to call — this means content was cut short by a page-budget limit, NOT that the book ended. An AI agent MUST NOT infer end-of-book from pages_returned alone; check truncated first. Daily page budgets apply across get_book_text/get_quote/get_quotes: anonymous 500 pages/24h, signed-in 1,000, free Explorer keys 2,000, paid keys uncapped — sign in at sourcelibrary.org/auth/signin or get a key at sourcelibrary.org/developers. Corpus-scale text belongs on the dataset API (sourcelibrary.org/dataset), not on this tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd page number (inclusive). Recommended chunk size: 50 pages. If the response has truncated=true, use the next from/to from truncation_note.
fromNoStart page number (inclusive). Use with to for explicit page ranges.
langNoISO code of the EDITION to read, e.g. "es". Default "en". Resolved PER PAGE: a page with no text in that language comes back as English, labelled `translation_lang: "en"` (json) or `[Translation — en]` (plain), and the response carries lang_coverage. Chapter text is materialized in English only, so `chapter` with a non-English `lang` is served from the chapter's page range instead.
partNoPart number (1-based) for large chapters split into multiple parts
formatNojson (default, structured with per-page fields) or plain (concatenated text with page markers)
book_idYesThe book ID
chapterNoChapter index (0-based). Preferred over from/to — returns pre-structured chapter text with embedded [Page N] markers.
contentNoWhich text to include: ocr (original language), translation (English), or both (default)

TDQS

A4.8/5.0
Behavior5/5

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

Massive behavioral context beyond annotations: truncation semantics, truncated flag, truncation_note for resuming, daily page budgets, auth tiers, per-page language fallback behavior, and the explicit warning not to infer end-of-book from pages_returned. Annotations already mark readOnly/idempotent, and the description adds significant operational detail.

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?

The description is long but well-structured into pipeline, truncation, budget, and scope sections. Every sentence provides actionable information; no filler. Slightly dense, but the tool's complexity and the absence of an output schema justify the length.

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 complex 8-parameter read tool with no output schema, the description covers return signals (truncated, truncation_note, lang_coverage, page markers), usage patterns, budget limits, and authentication paths. Nothing critical an agent needs to call this correctly 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 covers 100% of parameters, so the baseline is 3. The description adds semantic value by recommending chapter over from/to, explaining truncation_note supplies next from/to values, and clarifying language resolution behavior. This goes beyond the schema descriptions, though the schema already carries substantial per-parameter meaning.

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?

Description clearly states the action ('Read a book's text') and places it in the READ PIPELINE as step 2, distinguishing it from get_book (step 1) and get_quote/get_quotes (step 3). The verb+resource+stage is specific and unambiguous.

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?

Provides explicit guidance: call get_book first, prefer chapter over from/to, use get_quote/get_quotes for citations, and use the dataset API for corpus-scale text. This gives an agent clear decision rules for when to use this tool versus siblings.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation4/5

Tools are organized around distinct actions—discover, read, cite, search, contribute—and the descriptions cross-reference each other heavily. The only mild ambiguities are the get_quote/get_quotes pair and the multiple passage-search variants, which overlap in result type but are scoped differently.

Naming Consistency5/5

All tools use snake_case verb_noun names with predictable prefixes: get_* for retrieval, list_* for catalog enumeration, search_* for discovery, and plain verb_noun for contribution actions. Pluralization and compound nouns like get_book_text are minor variations that do not break the pattern.

Tool Count5/5

Fifteen tools is at the upper end of the ideal range, but every tool maps to a distinct step in the library workflow: discovery, reading, citation, search, editions, images, and community contributions. None feels redundant or decorative.

Completeness5/5

The surface covers the full research lifecycle: discovering books, reading them, locating canonical references, citing exact pages, searching by keyword/meaning/within a book, comparing editions, finding images, and contributing findings back. The pipeline from get_book to get_book_text to get_quote provides clear forward paths with no dead ends.

Resources