Skip to main content
Glama

Search every catalogue at once

search_items
Read-onlyIdempotent

Search the Internet Archive and Library of Congress catalogues in one query. Get a merged result list, with each item showing which archive it came from.

Instructions

Search the catalogue of every archive this server reads, at the same time, for a title, a creator or a subject, and get one merged list. Each row carries the id get_item takes, and that id names the archive it came from, so nothing has to be guessed afterwards. 'media_type' keeps one name across the archives and a vocabulary per archive, because the same word does not name the same set of things twice. An archive that files nothing under the name you give is not asked and is named as absent, with its own names listed, rather than asked under a translation. An archive that keeps one catalogue per kind of material is asked for its default when you name none, and the answer says which catalogue that was. Rows are interleaved one archive at a time. No score orders them against each other, and 'sort' is applied inside each archive rather than across them: a year is the date of an edition in one place and the date on a catalogue record in another, so there is no date order that spans the answer. Every count in 'per_source' is that archive's own and counts something of its own. They are never added together, and there is no total across archives. A row states no terms of reuse. Read the record with get_item for what that record itself says, and read silence as silence. Use search_inside for a phrase printed on a page: this tool reads catalogue records and knows nothing of what a book says, so a sentence given here matches only where a catalogue happens to carry it. Answers take several seconds, because one of the archives publishes a request ceiling this server keeps to.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoWhich page of rows, from 1. Each archive is paged separately.
sortNoApplied inside each archive. The merged list stays interleaved, because no order runs across archives.relevance
limitNoRows to take from each archive, so one archive cannot fill the whole list.
queryYesA title, a creator, a subject, or plain words.
sourcesNoArchives to ask, by id. Left out, they are all asked, which is the point of this tool.
year_toNoLatest year, in each archive's own reading of what a year is.
year_fromNoEarliest year, in each archive's own reading of what a year is.
media_typeNoThe kind of material, in the vocabulary of whichever archive uses that name. the Internet Archive files texts, movies, audio, image, software, data, web; the Library of Congress files books, photos, maps, audio, film-and-videos, manuscripts, notated-music, newspapers. The names are the union of those vocabularies rather than a shared one, so an archive that does not use the name you give is named as absent rather than asked under another. Naming none leaves an archive that searches every kind unnarrowed and asks an archive that keeps one catalogue per kind for its own default.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYes
itemsYes
notesYes
orderYesHow the list was built, in words.
queryYes
item_countYesRows in this answer, across every archive. Never a total of what exists.
per_sourceYes
media_typesYesWhich name each archive was asked under, published rather than reconciled, so a caller can map the vocabularies once and read what was actually searched.
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, the description discloses key behavioral traits: rows are 'interleaved one archive at a time,' no cross-archive ordering, per_source counts are per-archive and 'never added together,' and 'Answers take several seconds.' It also explains media_type handling and default archive selection. This adds significant context beyond the structured annotations.

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 long but every sentence serves a purpose, covering purpose, data semantics, ordering, counts, reuse, and performance. It is front-loaded with the core purpose and logically structured. No redundant or fluff content is present.

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 tool's complexity (8 parameters, multiple archives with distinct vocabularies and behaviors, interleaved results), the description is exceptionally complete. It addresses return value semantics (merged list, per_source), pagination behavior, limitations (no full-text, no cross-archive ordering), and latency. The existence of an output schema does not leave gaps.

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

Parameters5/5

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

Although schema coverage is 100%, the description enriches parameter meaning. For example, 'sort is applied inside each archive' and 'Rows are interleaved one archive at a time' clarify the sort parameter's semantics. It also explains sources ('Left out, they are all asked'), limit ('Rows to take from each archive'), and media_type vocabulary differences. This goes well beyond the schema descriptions.

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 opens with a specific verb and resource: 'Search the catalogue of every archive this server reads, at the same time, for a title, a creator or a subject, and get one merged list.' This clearly states the tool's scope and output. It distinguishes from siblings by explicitly directing full-text searches to search_inside and record retrieval to get_item.

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?

Explicit guidance is given: 'Use search_inside for a phrase printed on a page: this tool reads catalogue records and knows nothing of what a book says' and 'Read the record with get_item for what that record itself says.' This clearly states when to use the tool versus alternatives and what it is not for.

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