Skip to main content
Glama
ianderso

nara-catalog-mcp

by ianderso

search_records_advanced

Read-only

Filter National Archives Catalog records by date range, record group, microform number, ancestor NAID, or online availability to pinpoint the right records behind a common name.

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. Changed1 schema field changedv1.0.2
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds real behavioral context beyond them: the 'every parameter is optional but at least one is required' constraint, the identical result shape to search_records, and the pagination cliff past 10,000 hits. It does not discuss rate limits or response size beyond the include_extracted_text warning, so it is good rather than comprehensive.

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 scoping sentence and the 'at least one required' constraint are front-loaded, and the third paragraph handles an important edge case (pagination). Three short paragraphs with little waste, though the middle paragraph is more of a tour of parameters than a tight decision rule.

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?

For a 31-parameter tool with no output schema, the description usefully states that results match search_records' summaries and explains cursor behavior and the response-size cost of include_extracted_text. Combined with 100% schema coverage, an agent has what it needs; only the absence of any fallback/broad-search guidance when filters are unknown keeps it from a 5.

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% and the schema itself carries rich per-parameter documentation (exact_date conflicts, search_after '*' requirement, level_of_description values). The description adds prioritization ('filters that earn their keep') rather than new syntax or format meaning, so it is useful framing layered on a schema that already does the heavy lifting.

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?

The first sentence states a specific verb and resource ('Search the Catalog') and the modifier 'with the filters that narrow a common name' signals the advanced/filtered character of this tool. It also ties itself to a sibling by noting 'Results are the same summaries search_records returns', clarifying the relationship. It stops short of an explicit "use this instead of search_records when..." statement, so it is clear but not maximally differentiating.

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 gives concrete when-to-use guidance by naming which filters matter for research and why ('available_online when you intend to read pages rather than order copies'). It also routes between mechanisms: 'Past 10,000 hits use the next_search_after cursor rather than page'. There is no explicit when-not-to-use or a direct sibling comparison to search_records, so it is strong but not exhaustive.

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