Skip to main content
Glama

Find a phrase in the scanned text of every archive

search_inside
Read-onlyIdempotent

Find where a phrase appears in the full text of Internet Archive and Library of Congress at once, with page numbers and excerpts for each match.

Instructions

Search the machine-read text of every archive this server reads that holds any, at the same time, and get one list of where a phrase was printed. The archives behind this tool hold different material, so the list is additive: it is the places a phrase appears in each corpus, put together, rather than the same question answered twice. 'per_source' names what each corpus is. A match carries 'page_number', which is a real leaf on an archive whose index holds one and null on an archive whose index holds none. That null is the index having no leaf, never a page this server dropped, and no page is ever invented. A match also carries 'excerpt_kind'. 'passage' is the text around the words that matched. 'page_opening' is the start of the page, sent because the machine-read text that came back stops before the searched words appear, so it does not carry the match. The notes say how many excerpts are openings. Every count is that archive's own and counts something of its own: documents in one place, leaves in another. They are never added together, and there is no total across archives. Rows are interleaved one archive at a time. Nothing ranks them against each other and nothing orders them by date, because a year is measured on different things in each archive. Use search_items for a work by its title, its creator or its subject: this tool reads the text on the pages and knows nothing of a catalogue, so a title given here finds every book that happens to mention it and misses the book itself. Answers take several seconds, because one of the archives publishes a request ceiling this server keeps to. A slow answer is the pacing, not a stall.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoWhich page of matches, from 1. Each archive is paged separately.
limitNoMatches to take from each archive, so one archive cannot fill the whole list. The text block shows about six matches; the rest of what comes back is in the structured output.
queryYesWords, or a phrase in double quotes such as '"call me ishmael"'.
sourcesNoArchives to ask, by id. Left out, every archive that reads machine-read text is asked, which is the point of this tool.
max_excerpt_charsNoBudget for one passage. Read it together with 'max_excerpts_per_match': the size of the answer is the product of the two, the limit, and the number of archives.
max_excerpts_per_matchNoPassages to keep per match. A long work matches in several places, and the later ones rarely say anything the first did not.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsYes
pageYes
notesYes
orderYesHow the list was built, in words.
queryYes
hit_countYesMatches in this answer, across every archive. It is a count of what came back, never a total of what exists.
per_sourceYes
excerpt_kindsYesHow many excerpts here are of each kind.
Behavior4/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior, so the description's main added value is about aggregation semantics: it warns that results are additive per archive, counts are never totaled, ordering is not global, and page_number has a special null meaning. It also explains the excerpt_kind values and latency. It doesn't explicitly discuss authentication or rate limits beyond the pacing note, but the description substance goes well beyond what annotations convey.

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

Conciseness3/5

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

The description is thorough and well-organized, front-loading the core purpose, but it is quite long and somewhat dense. Each sentence adds meaningful semantic detail, but the dense prose mixes behavioral caveats and parameter guidance, making it harder to parse quickly. It is efficient, but shorter topic sentences or bullet-like separation would improve readability.

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 complex multi-archive tool, the description covers the semantic pitfalls: additive results, non-comparable counts, page_number null semantics, excerpt_kind variants, and latency. With a rich output schema and full parameter schema, it doesn't need to restate every field. It might omit explicit guidance on pagination interactions (page per archive), but the schema already states that, and the description notes rows are interleaved one archive at a time. Overall the description is sufficient.

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 the schema already documents all six parameters. The description adds useful cross-parameter semantics: it explains that max_excerpt_chars and max_excerpts_per_match multiply to determine answer size, that limit applies per archive, and that sources omitted means all archives. It also clarifies the meaning of page_number and excerpt_kind, which are response fields rather than parameters. A baseline of 3 holds for full schema coverage, but the additional guidance about products and per-archive behaviors pushes it to 4.

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 clearly identifies the tool as a full-text search across multiple archives: 'Search the machine-read text of every archive this server reads...' and emphasizes the additive, cross-corpus nature. It distinguishes itself from the sibling search_items by explicitly contrasting phrase-in-text versus catalogue metadata search.

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 states when to use this tool (find a phrase in scanned text) and explicitly when not to: 'Use search_items for a work by its title, its creator or its subject: this tool reads the text on the pages and knows nothing of a catalogue.' It also clarifies that queries are treated literally, so a title here finds mentions rather than catalogue entries, and warns about multi-second latency due to rate limits.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/smeet666/mcp-books'

If you have feedback or need assistance with the MCP directory API, please join our Discord server