Skip to main content
Glama

Source Library

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

Get Quotes (batch)

get_quotes
Read-onlyIdempotent

READ PIPELINE step 3 — CITE, in batch. Get verbatim text + citation_link for SEVERAL pages of a single book in one round-trip, to assemble a multi-passage dossier. Specify either pages (an explicit array, e.g. [12, 40, 41]) or an inclusive from/to range. Max 25 pages per call. Each entry carries its own citation_link to present alongside the quote, and — on non-Latin-script pages that have one — a romanized layer to show between the original and the translation (AI apparatus, not a transcription). Every entry also carries text_source: translation normally, or ocr_original on a leaf that is already English, where the verbatim text is original and must be attributed as the source's own words rather than as a translation. One batch can mix both — a Latin volume can hold an English preface. Batch pages count toward the shared daily page budget (see get_book_text); this is a citation tool, and corpus-scale extraction belongs on the dataset API (sourcelibrary.org/dataset).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoEnd page (inclusive) of a range. Use with from.
fromNoStart page (inclusive) of a range. Use with to.
langNoISO code of the EDITION to quote, e.g. "es". Default "en". Resolved per page — one batch can mix editions, so read `quote.lang` on each entry rather than assuming the whole dossier is in one language.
pagesNoExplicit list of page numbers (e.g. [12, 40, 41]). Use this OR from/to.
book_idYesThe book ID
include_imageNoAlso return page scans as inline images (display size). The first 5 pages of the batch get inline image blocks; every entry still carries its page_image_url in the JSON.

TDQS

A4.8/5.0
Behavior5/5

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

An annotation already provides readOnlyHint and idempotentHint, but the description goes well beyond that by disclosing romanized-layer behavior, text_source semantics, mixed-edition handling, daily page-budget impact, and include_image's first-5-pages inline behavior. These are non-obvious behaviors an agent needs to know before calling the tool.

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

Conciseness5/5

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

The description is dense but every sentence carries load: purpose, invocation modes, limits, return-entry fields, edge cases, and budget/API exclusions. It is front-loaded with the core purpose and uses concrete examples like [12, 40, 41] without padding.

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 takes on the burden of explaining return behavior, and it does: citation_link, romanized layer, text_source, quote.lang, and page_image_url are all named. It also covers mixed batch composition, daily budget, and the boundary against the dataset API, so an agent has enough context to invoke the tool correctly.

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?

Although schema coverage is 100%, the description adds essential semantics not in the schema: pages is an alternative to from/to rather than additive, the 25-page maximum, per-page language resolution requiring the agent to read quote.lang, and concrete include_image behavior with inline image blocks versus page_image_url. This meaningfully improves parameter understanding.

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 description opens with a specific verb and resource: 'Get verbatim text + citation_link for SEVERAL pages of a single book in one round-trip.' It clearly identifies the batch nature of the tool, distinguishing it from the singular sibling get_quote, and places it in context as 'READ PIPELINE step 3 — CITE.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use it: to assemble a multi-passage dossier from several pages, with explicit page/range specification and a 25-page cap. It also excludes corpus-scale extraction by directing that to the dataset API. However, it does not explicitly say 'use get_quote for a single quote,' leaving that particular alternative to inference.

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