Skip to main content
Glama

Source Library

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

List Books

list_books
Read-onlyIdempotent

BROWSES/FILTERS THE CATALOG by metadata (canonical author via author_id, author/title fragment via search, language, category, year range, translation recency) — no content/topic matching. PICK THIS to see WHAT EXISTS by an author or in a tradition, or to enumerate a date range. Returns books with title, author (string + canonical author_id + author_url), language, year, and translation progress. → For a relevance-ranked topic search use search_library; for passages on a theme use search_translations (exact words) or search_concept (by meaning).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNo
limitNoMax results (default 100, max 200)
searchNoFree-text filter matching title or author (relevance-ranked, may include title matches). For exactly one person's books use author_id instead.
year_toNoLatest edition year (inclusive).
categoryNo
languageNo
author_idNoCanonical author slug, e.g. "jan-hus" — filters to exactly that person's books via the author thesaurus (variant slugs resolve to the canonical person). Every book row in results carries its author_id; the response echoes the canonicalized author.
year_fromNoEarliest edition year (inclusive). Matches only books with a known numeric year — ~60% of the library.
edition_keyNoOther digitizations of ONE printing — pass the edition_key from a result row. Only full-quality keys match on both sides, so this answers "what other scans of this exact edition do you hold?" and never merges different printings of the same title.
has_editionNoISO code — return only books READABLE in that language, e.g. "es". Different from `language`, which is the language printed on the leaves of the scan: a Latin book with a Spanish edition matches language="Latin" AND has_edition="es". Each result then also carries url_localized.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/destructive safety. The description adds useful behavioral context beyond annotations: it is metadata-only, does not do content/topic matching, and describes the returned book fields. This exceeds the baseline while avoiding contradiction.

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 information-dense and front-loaded with the core purpose and the content-matching exclusion. It is somewhat run-on and uses heavy formatting, but every part earns its place and there is no redundancy.

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?

For a 10-parameter tool with no output schema, the description covers the main use case, return fields, and sibling routing. It does not spell out behavior for every parameter, but the schema descriptions fill that gap, so the description is sufficiently complete for correct tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description groups the parameters into meaningful filter categories (author_id, search fragment, language, category, year range, translation recency) and adds the 'metadata only' interpretation. However, it omits edition_key and has_edition, and does not provide per-parameter format or matching details; the schema descriptions carry most of the burden.

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 states a specific verb and resource: it browses/filters the catalog by metadata. It also explicitly excludes content/topic matching, which clearly distinguishes it from sibling search tools.

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?

It says exactly when to pick this tool ('PICK THIS to see WHAT EXISTS...') and explicitly routes to alternatives: search_library for relevance-ranked topic search, search_translations for exact words, and search_concept for meaning-based search. This is strong when-to-use vs alternatives guidance.

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