libofcongress-mcp-server

Search LOC Collections

libofcongress_search

Read-only

Search the Library of Congress digital collections by keyword. Optionally filter by material format (photos, maps, newspapers, audio, etc.), date range, subject heading, or geographic location, or scope the search to a single curated collection with collection_slug. Returns item summaries with titles, dates, descriptions, LOC IDs, and format tags. Each result carries is_item: pass the id of a result where is_item is true to libofcongress_get_item for full metadata; results where is_item is false are non-item resources (collections, exhibit and research-guide pages, newspaper-page results) with no item record — open their url instead. Use libofcongress_search_subjects first to find the exact LCSH heading spelling before applying a subject filter.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No	1-indexed page number for paginating results.
`limit`	No	Results per page. Default 25, max 100.
`query`	Yes	Full-text search across metadata and available descriptive text.
`format`	No	Material type filter. Options: photo, map, newspaper, manuscript, audio, film, book, notated-music. Omit to search all formats.
`subject`	No	Subject heading filter. Use the exact label from libofcongress_search_subjects results for best precision. Example: "World War, 1939-1945".
`date_end`	No	End year for date filter, inclusive (e.g., 1930). Omit for no upper bound.
`location`	No	Geographic location filter (e.g., "oklahoma", "washington d.c."). Lowercase, matches LOC location facets.
`date_start`	No	Start year for date filter, inclusive (e.g., 1920). Omit for no lower bound.
`collection_slug`	No	Scope the search to one curated collection. Use a slug exactly as returned by libofcongress_browse_collections (e.g., "aaron-copland") — slugs are not derivable from the collection title. Cannot be combined with format; omit format and read each result's format field instead. Omit to search all of LOC.

Output Schema

TableJSON Schema

Name	Required	Description
`page`	No	Current 1-indexed page number.
`error`	No	Present when the call failed. Absent on success.
`items`	No	Item summaries matching the search query and filters.
`pages`	No	Total retrievable pages. For result sets larger than LOC will page through (~100,000 items) this is capped, and a notice discloses how to reach the rest (partition by date/subject/location).
`total`	No	Total number of matching items across all pages.
`notice`	No	Recovery hint when results are empty or a page is out of range — echoes applied filters and suggests how to broaden. Absent on successful result pages.
`has_next`	No	True when a retrievable next page follows this one. Never promises a page past LOC's ~100,000-item retrieval ceiling.
`totalCount`	No	Total matching items across all pages — mirrors output.total for agent reasoning.
`effectiveQuery`	No	The query as submitted to the LOC API, after trimming.
`effectiveCollectionSlug`	No	The collection the search was scoped to, after trimming. Absent when the search covered all of LOC.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 22, 2026

changedOutput schema / properties / error / properties / data / properties / reason / description

Previous value: -"Machine-readable failure mode. Declared by this tool: `incompatible_filters`: format and collection_slug were both supplied; each selects a different LOC endpoint, so only one can apply. `collection_not_found`: collection_slug does not resolve to a LOC collection. `rate_limit_exceeded`: LOC API rate limit exceeded; requests are blocked for approximately 1 hour. Other values are possible when a failure originates below the handler."New value: +"Machine-readable failure mode. Declared by this tool: `invalid_date_range`: date_start is later than date_end. `incompatible_filters`: format and collection_slug were both supplied; each selects a different LOC endpoint, so only one can apply. `collection_not_found`: collection_slug does not resolve to a LOC collection. Reported on page 1; a later page gets the out-of-range notice, since LOC answers both cases the same way there. `rate_limit_exceeded`: LOC API rate limit exceeded; requests are blocked for approximately 1 hour. Other values are possible when a failure originates below the handler."

changedOutput schema / properties / error / properties / data / properties / reason / examples

Previous value: -[
-  "incompatible_filters",
-  "collection_not_found",
-  "rate_limit_exceeded"
-]New value: +[
+  "invalid_date_range",
+  "incompatible_filters",
+  "collection_not_found",
+  "rate_limit_exceeded"
+]

First observedSep 19, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses a non-obvious behavioral contract: some results are not items, carry no item record, and must be handled by opening their url. It also specifies that each result has an is_item flag, which is exactly the kind of detail an agent needs before invoking downstream tools.

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?

Four dense sentences, each earning its place: the first states scope, the second lists filters, the third explains return-value handling, and the fourth gives a prerequisite workflow. Information is front-loaded and no filler 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?

Despite the high parameter count and five siblings, the description covers the non-obvious result-routing logic (is_item vs url) and a critical prerequisite (search_subjects for subject filters). With a full schema and output schema available, nothing agent-critical is missing.

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 structured schema already documents every parameter including the collection_slug constraint and subject-label requirement. The description echoes those points (subject heading spelling, collection_slug) without adding materially new parameter semantics beyond the schema.

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 description opens with a specific verb and resource ('Search the Library of Congress digital collections by keyword') and clarifies it returns item summaries. It implicitly distinguishes itself from libofcongress_get_item and libofcongress_search_subjects, but it never explicitly distinguishes itself from the sibling libofcongress_search_newspapers, so an agent may be unsure which newspaper search to pick.

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 workflow guidance: use libofcongress_search_subjects first for exact LCSH headings, route is_item=true results to libofcongress_get_item, and open the url for non-item results. It does not, however, state when to prefer this general search over libofcongress_search_newspapers or when to start from libofcongress_browse_collections.

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

All libofcongress-mcp-server tools Inspect

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.