Skip to main content
Glama
smeet666

mcp-archiveorg

Search inside scanned pages

search_inside
Read-onlyIdempotent

Search full text of digitized books, newspapers, and documents on the Internet Archive to find phrases even when metadata lacks them. Use quoted phrases for exact matches and page through results.

Instructions

Search the text inside digitised books, newspapers and documents on the Internet Archive. This reads what optical recognition took off the scanned pages, so it finds a phrase that appears nowhere in a title or a catalogue record. Put a phrase in double quotes to hold the words together in that order. The index folds accents, case and punctuation before it matches, so the letters are not held: a quoted "bûcher" comes back on pages printing Bücher and Bucher. Read an excerpt before repeating a quoted query as the spelling a page carries. Without quotes the words are matched separately, which finds far more. 'total' counts the documents that match, and they page: ask for page 2, 3 and so on to see beyond the first answer. It is not a count of how many times the phrase occurs. The index reports no page number, so a match names the item and the passage, never a leaf. Follow source_url and search the item to find where the passage sits. When 'inside_container' is true the passage came from a document bundled inside the item, and the title, creator and year describe the container rather than the text that matched: read 'matched_file' for what actually holds it. Use search_items or search_books instead when looking for a work by its title, author or subject.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoWhich page of matches, from 1. Paging stops at 100.
limitNoMatches to return.
queryYesWords or a quoted phrase, such as '"call me ishmael"'.
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 and the number of matches.
max_excerpts_per_matchNoPassages to keep per match. The index finds several in a long work, and the later ones rarely say anything the first did not.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsYes
pageYes
notesYes
queryYes
totalYesDocuments that match, not the number returned and not a count of occurrences. Raise 'page' to read further into it.
Behavior5/5

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

Beyond the readOnlyHint, the description discloses key behaviors: accent/case/punctuation folding, quoted phrase preservation, unquoted tokenization, the meaning of 'total' (document count, not occurrence count), lack of page numbers, and the inside_container nuance with matched_file. This is substantial behavioral context.

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 earns its place. It opens with the core purpose, then logically covers query syntax, matching behavior, pagination, result semantics, and edge cases, ending with alternatives. No fluff or repetition.

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 the output schema already documents return values, the description covers essential edge cases (accent folding, quoted vs unquoted, container documents, page limitations) and provides enough context for an agent to invoke the tool correctly. It feels complete for the tool's complexity.

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 thorough parameter descriptions. The description adds extra semantics for the query parameter (quoting, accent folding) and mentions paging behavior. It does not deeply explain limit or excerpt parameters, but schema already covers them, so the added value is meaningful without being fully compensatory.

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 states the tool searches full text inside scanned documents, explicitly distinguishing it from metadata search. It names the resource (digitised books, newspapers, documents) and the specific capability (optical recognition text), making the purpose 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?

The description provides explicit guidance on when to use this tool vs siblings: 'Use search_items or search_books instead when looking for a work by its title, author or subject.' It also explains quoting, accent folding, and paging behavior, giving clear usage context.

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-archiveorg'

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