mcp-archiveorg

Search inside scanned pages

search_inside

Read-onlyIdempotent

Search the full text inside digitized books, newspapers, and documents on the Internet Archive to find phrases that appear only on scanned pages, not in titles or catalog records.

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_inside"
  }
}

Input Schema

Name	Required	Description
`page`	No	Which page of matches, from 1. Paging stops at 100.
`limit`	No	Matches to return.
`query`	Yes	Words or a quoted phrase, such as '"call me ishmael"'.
`max_excerpt_chars`	No	Budget 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_match`	No	Passages 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

Name	Required	Description
`hits`	Yes
`page`	Yes
`notes`	Yes
`query`	Yes
`total`	Yes	Documents that match, not the number returned and not a count of occurrences. Raise 'page' to read further into it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv2.1.0Oct 30, 2026
- removedOutput schema / properties / hits / items / properties / creator / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / hits / items / properties / creator / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / hits / items / properties / matched_file / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / hits / items / properties / matched_file / type
```
Added value: +[
+  "string",
+  "null"
+]
```
- removedOutput schema / properties / hits / items / properties / title / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedOutput schema / properties / hits / items / properties / title / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changed1 schema field changedv1.5.0Aug 10, 2026

changedInput schema / properties / page / description

Previous value: -"Which page of matches, from 1."New value: +"Which page of matches, from 1. Paging stops at 100."

Changed1 schema field changedv1.3.0Aug 7, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedv0.1.0Aug 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Well beyond the readOnly/idempotent/openWorld annotations, it discloses non-obvious traits: the index folds accents, case and punctuation; 'total' counts documents not occurrences; the index reports no leaf number; and 'inside_container' means title/creator/year describe the container while 'matched_file' identifies the real source. This is exactly the behavioural context annotations cannot carry.

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?

Dense and front-loaded, with the core purpose in the first sentence and the sibling routing at the end where it belongs. It runs long and a few clauses (the 'bûcher' example, the repetition of excerpt advice) could be tightened, but almost every sentence carries unique operational value.

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?

For a phrase-search tool with an output schema, the description covers everything an agent needs: corpus, quoting semantics, paging limits, misleading 'total', absent page numbers, container vs. matched_file distinction, and where to go next via source_url. No material gap remains.

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?

Schema description coverage is 100%, so baseline is 3. The description reinforces query quoting behaviour and paging (pages 2, 3, ...) with more nuance than the schema, but adds nothing about limit, max_excerpt_chars or max_excerpts_per_match beyond what the schema already states, including the product relationship.

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 the specific verb and resource ('search the text inside digitised books, newspapers and documents') and immediately delimits it from sibling metadata search. The sentence about optical recognition cutting the pages makes it unmistakable what corpus is being queried versus search_items/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?

Gives explicit when-not routing: 'Use search_items or search_books instead when looking for a work by its title, author or subject.' It also prescribes query technique (quoted phrase vs. unquoted) and tells the agent to page for further results, so the calling conditions are fully specified.

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

Deploy Server