Skip to main content
Glama

openlibrary-mcp-server

by io.github.cyanheads

Search Inside Books

openlibrary_search_inside
Read-only

Search the full text of books scanned by the Internet Archive — the "which book contains this passage?" lookup that the metadata tools cannot answer. Quote a phrase for an exact-phrase match; bare terms match anywhere in the text. Each result is an Internet Archive item with the matching passages as snippets, plus a relevance score. The full-text index is an order of magnitude slower than the metadata endpoints (seconds, not milliseconds), so reach for it when the passage is the question, not as a general book search — use openlibrary_search_books for title, author, or subject. Results key on Internet Archive items rather than Open Library works: chain the returned ia_identifier to archive.org, or match it against the ia_identifiers on openlibrary_search_books results to reach the catalogue record.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax matching items to return. Each carries its own snippets, so higher values grow the response quickly — prefer 10–20.
queryYesText to find inside scanned books. Wrap in double quotes for an exact-phrase match (e.g., "the spice must flow"); unquoted terms match independently and return far broader results.
offsetNoZero-based offset for pagination.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNoPresent when the call failed. Absent on success.
totalNoTotal matching Internet Archive items across all pages.
noticeNoGuidance when the page is empty (how to broaden a query that matched nothing, or which offset to retry when offset ran past the end) or when the text output capped a per-item snippet list. Absent when neither applies.
offsetNoZero-based offset of the first returned match.
matchesNoMatching items, up to limit, ordered by relevance.
totalCountNoTotal matching items across all pages — the upstream match count, reported even when this page is empty because offset ran past the end.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint; the description adds significant behavioral context beyond these: the index is an order of magnitude slower, results are Internet Archive items rather than Open Library works, and the returned ia_identifier can be chained or matched. This is rich, non-redundant disclosure.

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 well-structured and front-loaded with the core purpose, followed by usage guidance and performance/result notes. It is efficient—about 100 words—and every sentence earns its place, though the final sentence on keying results could arguably be placed earlier. Still appropriately concise.

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?

Given an output schema is present (so return format is handled elsewhere), the description covers all essential context: purpose, usage, performance, result semantics, and tool routing. No pragmatic detail an agent needs to select and call this tool 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 coverage is 100% with descriptions for all three parameters, establishing a baseline of 3. The description adds extra value: explains quoting semantics for query, notes the response growth implication for limit and recommends 10-20, and clarifies offset's role. This exceeds the baseline without being verbose.

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 ('Search') and resource ('full text of books scanned by the Internet Archive'), and explicitly distinguishes it from metadata tools with the 'which book contains this passage?' framing. The purpose is unambiguous and easily differentiated from siblings like openlibrary_search_books.

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 when-to-use (passage lookup) and when-not-to-use (general book search) guidance, naming the alternative tool (openlibrary_search_books) and its intended use case (title, author, subject). Also clarifies quoting behavior for exact phrases, leaving no ambiguity about invocation.

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

All openlibrary-mcp-server 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.4/5.0
Disambiguation5/5

Every tool targets a distinct resource-action pair: author lookup, author works, cover resolution, edition resolution by identifier, edition listing by work, subject browsing, work lookup, and three search types (authors, books, full-text). The only near-overlap is get_edition vs get_editions, but the descriptions clearly separate identifier-based resolution from listing editions of a work, and cross-references reinforce the distinction.

Naming Consistency5/5

All tools follow a consistent snake_case verb_noun pattern: get_* for direct retrieval and search_* for query-based lookups. The single pair get_edition/get_editions is a natural pluralization, not an inconsistency. Naming is predictable and intuitive throughout.

Tool Count5/5

Ten tools is an ideal size for a read-heavy library API. Each tool serves a distinct purpose (author, work, edition, subject, cover, three search modes) without redundancy or bloat. The surface feels deliberately scoped and not overwhelming.

Completeness5/5

The set covers the full read surface of Open Library: authors (get/search), works (get/search), editions (get by ID, list by work), subjects, covers, and full-text search. There are no obvious missing operations—all core entities and lookup paths are represented, and recoveries for missing data (e.g., author names) are built into descriptions.

Resources