Skip to main content
Glama

Chronicling America

by io.github.pipeworx-io
OverviewDiscussionsAdmin

Search Newspapers

search_newspapers
Read-onlyIdempotent

Full-text search of digitized historical U.S. newspapers (~1690s–present) from the Library of Congress "Chronicling America" collection. Find primary-source newspaper coverage of any person, event, place, or topic in history — returns the total match count, then for each page the newspaper, publication date, city/state and a link to the digitized page (plus an OCR text excerpt of the matching page for covered states such as Montana). Filter by date range and U.S. state; every response carries data_as_of. Example: search_newspapers({ query: "influenza epidemic", date_from: "1918", date_to: "1919", state: "oklahoma" }).

Input Schema

NameRequiredDescriptionDefault
limitNoNumber of results (default 10, max 25).
queryYesFull-text search terms (matched against the OCR'd newspaper text).
stateNoU.S. state to restrict to: name or postal code (e.g. "california", "new york", "MT").
date_toNoLatest year or date (e.g. "1919"). Defaults to present.
date_fromNoEarliest year or date (e.g. "1918" or "1918-01-01"). Defaults to the collection start.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "date_from": "1918",
-    "date_to": "1919",
-    "query": "influenza epidemic",
-    "state": "oklahoma"
-  },
-  {
-    "date_from": "1849",
-    "date_to": "1855",
-    "limit": 20,
-    "query": "gold rush",
-    "state": "california"
-  }
-]New value: +[
+  {
+    "date_from": "1922",
+    "date_to": "1922",
+    "query": "flood",
+    "state": "montana"
+  },
+  {
+    "date_from": "1918",
+    "date_to": "1919",
+    "query": "influenza epidemic",
+    "state": "oklahoma"
+  },
+  {
+    "date_from": "1849",
+    "date_to": "1855",
+    "limit": 20,
+    "query": "gold rush",
+    "state": "california"
+  }
+]
    • changedInput schema / properties / state / description
      Previous value: -"U.S. state name to restrict to (lowercase, e.g. \"california\", \"new york\")."New value: +"U.S. state to restrict to: name or postal code (e.g. \"california\", \"new york\", \"MT\")."
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds useful behavioral context: total match count, per-page fields, OCR excerpt coverage caveat for certain states, and data_as_of in every response.

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?

The description is front-loaded with purpose and scope, then output details and an example. It is somewhat dense but each part is useful for an agent deciding whether and how to call the tool.

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?

With no output schema, the description explains the return shape (total count, newspaper, publication date, city/state, page link, OCR excerpt for covered states, data_as_of). Combined with annotations and full schema coverage, this is complete enough to call the tool correctly.

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 coverage is 100%, so the schema already documents all five parameters, including defaults and limits. The description reinforces date/state filtering and provides an example, but adds little parameter meaning beyond the schema.

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 states a specific verb and resource — full-text search of digitized historical U.S. newspapers from Chronicling America — and identifies the collection scope (~1690s–present). It is clearly distinguishable from generic search or archive-comparison siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It says to use the tool for primary-source newspaper coverage of a person, event, place, or topic, and mentions date/state filtering plus an example. It does not explicitly name when to choose it over siblings like archive_compare or search_within, so it stops short of full alternative routing.

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

All Chronicling America toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources