Skip to main content
Glama
ianderso

nara-catalog-mcp

by ianderso

search_records_advanced

Read-only

Apply multiple filters like date range, record group, or microfilm publication to search the NARA Catalog and find targeted archival records.

Instructions

Search the Catalog with the filters that narrow a common name.

Every parameter is optional but at least one is required. The filters that earn their keep for research are the date range, microform_publication for an M-number you already cite, record_group_number or ancestor_naid to stay inside one body of records, and available_online when you intend to read pages rather than order copies.

Results are the same summaries search_records returns. Past 10,000 hits use the next_search_after cursor rather than page; a common surname passes that boundary easily.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage of results, 1-based. Ignored when search_after is given, and unusable past 10,000 results.
exactNoMatch title, local_identifier and microform_publication in full and exactly, instead of by words within them. Use it when a words match returns too much, or you hold the complete title.
limitNoMaximum records to return (1-100).
queryNoFull-text search across the whole description.
titleNoWords to match in the record title.
creatorsNoThe agency or person who created the records, matched against the creator headings.
end_dateNoLatest date to include, in the same format as start_date.
exact_dateNoA single date, YYYY-MM-DD. Cannot be combined with start_date or end_date.
start_dateNoEarliest date to include, as YYYY, YYYY-MM or YYYY-MM-DD. Use the same precision as end_date. A surname search is usually only workable once it is bounded to a lifetime.
tags_existNoTrue for records carrying citizen tags.
data_sourceNo'description' for archival descriptions, 'authority' for authority records (people, organisations, topics). This narrows a search and cannot be one on its own.
search_afterNoCursor for paging past 10,000 results. You MUST pass '*' for the first page, then the 'next_search_after' value from each response. Starting from an ordinary search does not work: without '*' the results are relevance-sorted and their cursor is not resumable. Cannot be combined with page.
ancestor_naidNoNAID of an ancestor node: returns only records below it in the hierarchy. Use it to search inside one series.
person_or_orgNoA person or organisation named in the description, either as its subject or in a role such as creator. Distinct from `creators`, which is the record's creating body only.
recurring_dayNoDay as DD. Normally used with recurring_month.
comments_existNoTrue for records carrying researcher comments.
congress_numberNoRecords of one numbered Congress, e.g. 55 for 1897-99. Private relief bills, petitions and claims naming individuals sit in the records of Congress.
control_numbersNoAny identifier NARA attaches to a record: accession number, local identifier, microfilm publication, NAID, transfer number or variant control number. For a citation whose kind you cannot name.
recurring_monthNoMonth as MM. With recurring_day, finds records dated to that day in any year -- a birthday across every census.
reference_unitsNoName of the archive holding the paper, e.g. 'National Archives at St. Louis'. Comma-separate several.
available_onlineNoTrue for digitised records only -- those whose pages you can read now rather than order from a reading room.
local_identifierNoThe archives' own identifier for the record, as printed in finding aids.
type_of_materialsNoMaterial type, e.g. 'Textual Records', 'Photographs and other Graphic Materials', 'Maps and Charts', 'Moving Images'.
contributions_existNoTrue for records carrying any contribution at all: a transcription, tag or comment. Someone has already worked on them.
record_group_numberNoRecord group number, e.g. '15' for Veterans Affairs. Scopes the search to one agency's records.
geographic_referenceNoPlace the records are about, matched against geographic subject headings, e.g. 'Franklin County (Pa.)'.
level_of_descriptionNoOne of recordGroup, collection, series, fileUnit, item. A case file is usually a fileUnit; a single page is an item.
transcriptions_existNoTrue for records someone has transcribed; False for ones nobody has. Transcribed records are searchable by their text.
collection_identifierNoCollection identifier, the Presidential-library equivalent of a record group.
microform_publicationNoMicrofilm publication number, e.g. 'M804' for Revolutionary War pension applications or 'T624' for the 1910 census. This is the citation genealogists actually carry.
include_extracted_textNoFold each hit's OCR text into the response, saving a call per hit: each record gains an extracted_text list with one entry per page that carries text, NARA's own OCR or a partner's, capped at 2000 characters each. It makes the response much larger, so use it on a narrowed search rather than a broad one; get_extracted_text returns whole pages.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral context beyond that: results are the same summaries `search_records` returns, and a hard 10,000-hit boundary forces the `next_search_after` cursor instead of `page`. It stops short of describing ordering or response size tradeoffs beyond the paging note.

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?

Three short paragraphs, front-loaded with purpose, then filter selection, then paging. No filler sentences; each one carries a distinct instruction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 31 parameters, no output schema and no required fields, the description does well to explain the at-least-one-rule, result shape and cursor mechanics. It could go further on what the returned record summaries contain, but for a tool whose schema is fully documented this is close to sufficient.

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 description coverage is 100%, so the baseline is 3. The description still earns above that by adding strategic meaning the schema lacks — e.g. using `available_online` only when the user intends to read pages rather than order copies, and bounding a surname search by date. It adds selection rationale rather than restating field definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (search) and resource (the Catalog) plus the distinguishing scope — the filter-heavy variant that narrows a common name. However, it never explicitly positions itself against the sibling `search_records`; it only mentions that sibling to describe the return shape, not to explain which tool to pick. A clear purpose, but sibling differentiation is left implicit.

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?

Gives concrete research-oriented guidance on which filters matter (date range, microform_publication, record_group_number/ancestor_naid, available_online) and the rule that at least one parameter is required. It does not, however, say when NOT to use this tool or explicitly route the agent to `search_records` for the simpler case.

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