Skip to main content
Glama
smeet666

mcp-libraryofcongress

Search inside scanned newspaper pages

search_newspapers
Read-onlyIdempotent

Search the full text of digitized American newspaper pages from the Library of Congress to locate specific phrases or keywords, with optional filters for state, publication, and year range.

Instructions

Search the text inside digitised American newspaper pages held by the Library of Congress. 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 match it whole; without quotes the words are matched separately, which finds far more. 'total' counts the pages 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 words occur. Each match names the newspaper, the date, the leaf of the issue and the state it was published in, and 'source_url' opens that leaf with the query applied. 'location' keeps to papers published in one state, 'publication' to a single paper, and 'year_from' with 'year_to' to a span of years. A filter matching nothing is dropped and the answer says so. The Library returns the opening of a page's text with each row rather than the whole page, so the searched words are often further down than the excerpts reach: 'words_located' says which of the two happened for each match. Use search_items instead when looking for a work by its title, creator or subject.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoWhich page of matches, from 1.
limitNoMatches to return.
queryYesWords or a quoted phrase, such as '"cure for influenza"'.
year_toNoLatest year, inclusive.
locationNoThe state a paper was published in, written as the Library writes it: 'new york', 'district of columbia'. It is the value 'state' carries on the matches this tool returns.
year_fromNoEarliest year, inclusive.
publicationNoOne newspaper, named with its town and the years it ran: 'new-york tribune (new york [n.y.]) 1866-1924'. Take the wording from 'publication' on a match here, or from a title in search_items with media_type 'newspapers'.
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. A page holding the words several times yields several, and the later ones rarely say anything the first did not.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsYes
pageYes
notesYes
queryYes
totalYesNewspaper pages 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?

Goes well beyond the annotations by revealing important quirks: OCR text may contain errors, 'total' is not a term-frequency count, filters that match nothing are dropped (and the response says so), and excerpts only show the beginning of a page's text, with 'words_located' indicating whether the search terms fell within the excerpt. These details help the agent set expectations and handle results correctly.

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 provides useful information, from the OCR context to pagination to output field explanations. It is front-loaded with the core purpose and avoids fluff. Although lengthy, the detail is justified by the tool's complexity and the need to work around Library of Congress API quirks.

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?

Covers the tool's purpose, OCR-specific behavior, pagination rules, filters, output fields, edge cases (dropped filters, excerpt truncation), and explicitly contrasts with search_items. With an output schema available, it is more than sufficient for an agent to decide when and how to invoke this tool.

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?

Although the input schema already has 100% description coverage, the tool description adds meaningful behavioral context for several parameters: 'location' limits to a state, 'publication' to a single paper, 'year_from'/'year_to' define a year range, and 'page' is used for pagination. It does not deeply elaborate on every parameter, but the added context lifts it above the baseline.

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's function: full-text search within digitised American newspaper pages from the Library of Congress. It distinguishes itself from the sibling tool search_items by explicitly saying 'Use search_items instead when looking for a work by its title, creator or subject.'

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 usage guidance: advises using double quotes for exact phrases, explains that unquoted matches are broader, tells how to paginate with 'page', and gives the alternative tool for title/creator/subject searches. It also describes how filters like 'location', 'publication', and 'year_from'/'year_to' narrow results.

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

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