Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@historical-investigator-mcp Search for newspaper articles about the 1906 San Francisco earthquake in California"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A beginner-friendly Model Context Protocol (MCP) server that searches historical records from the Library of Congress APIs.
Built with TypeScript, Node.js, the official @modelcontextprotocol/sdk, and zod for input validation.
npm install
npm run buildRelated MCP server: Gospel Library MCP
The server communicates over stdio (standard for MCP):
npm startAdd this to your MCP settings (for example in Cursor):
{
"mcpServers": {
"historical-investigator": {
"command": "node",
"args": ["/absolute/path/to/historical-investigator-mcp/dist/index.js"]
}
}
}Replace the path with your local clone of this project.
search_historical_newspapersSearch historical newspaper records from Chronicling America via the Library of Congress API.
Parameter | Type | Required | Description |
| string | yes | Search keywords |
| string | no | US state name or abbreviation |
| string | no | Start date ( |
| string | no | End date ( |
| number | no | Max results (1–100, default 20) |
Example prompt: “Search Chronicling America for articles about the San Francisco earthquake in California between 1906-04-01 and 1906-04-30.”
Uses the Chronicling America collection endpoint with:
q — keyword search
fa=location:{state} — state filter (e.g. location:california)
start_date / end_date — date range (YYYY-MM-DD)
c — result limit
fo=json — JSON response
The response includes a requestUrl field with the exact LOC API URL used, which helps with debugging.
Date filtering limitation: The LOC API accepts start_date and end_date, but results are not always strictly limited to that range. You may see newspaper pages from nearby dates (or later years) when the search terms appear in OCR text. If you need an exact date window, check each result’s date field and filter client-side.
get_newspaper_itemFetch metadata for a specific LOC item or resource.
Parameter | Type | Required | Description |
| string | yes | Item ID (e.g. |
Example prompt: “Get metadata for LOC item 2014717546.”
fetch_page_ocr_textDownload raw OCR plain text from a URL (often found in item metadata).
Parameter | Type | Required | Description |
| string | yes | URL to the OCR text file |
Example prompt: “Fetch the OCR text from this URL: …”
Returns plain text. Errors are handled safely and reported back to the client.
search_prints_and_photographsSearch prints and photographs in the LOC collections.
Parameter | Type | Required | Description |
| string | yes | Search keywords |
| number | no | Max results (1–100, default 20) |
Uses: https://www.loc.gov/photos/ with fo=json.
search_mapsSearch map records in the LOC collections.
Parameter | Type | Required | Description |
| string | yes | Search keywords |
| number | no | Max results (1–100, default 20) |
Uses: https://www.loc.gov/maps/ with fo=json.
search_manuscriptsSearch manuscript records in the LOC collections.
Parameter | Type | Required | Description |
| string | yes | Search keywords |
| number | no | Max results (1–25, default 10) |
Uses: https://www.loc.gov/manuscripts/ with fo=json.
Returns trimmed fields: title, date, contributor, description, subjects, and item link.
search_audio_recordingsSearch audio recordings in the LOC collections.
Parameter | Type | Required | Description |
| string | yes | Search keywords |
| number | no | Max results (1–25, default 10) |
Uses: https://www.loc.gov/audio/ with fo=json.
Returns trimmed fields: title, date, contributors, description, subjects, and item link.
search_film_and_videoSearch film and video records in the LOC collections.
Parameter | Type | Required | Description |
| string | yes | Search keywords |
| number | no | Max results (1–25, default 10) |
Uses: https://www.loc.gov/film-and-videos/ with fo=json.
Returns trimmed fields: title, date, contributors, description, subjects, and item link.
get_item_resourcesFetch a specific LOC item or resource and return digital files when available.
Parameter | Type | Required | Description |
| string | yes | Item ID, resource path, or full loc.gov URL |
Returns title, date, item link, resources/files/images/OCR links when present. If nothing is digitized, returns a helpful message.
compare_historical_sourcesCompare two LOC records side by side using metadata only (no AI summarization).
Parameter | Type | Required | Description |
| string | yes | First item ID or full loc.gov URL |
| string | yes | Second item ID or full loc.gov URL |
Returns both records (title, date, location, contributors, subjects, description, link) plus a comparison object with same_year, shared_subjects, and source_types.
historical-investigator-mcp/
├── src/
│ └── index.ts # MCP server and LOC API helpers
├── package.json
├── tsconfig.json
├── README.md
└── .gitignoreAll LOC requests use fo=json for JSON responses.
Newspaper searches use q, optional fa=location:..., and optional start_date / end_date on the Chronicling America collection endpoint.
Photo and map searches use the /photos/ and /maps/ format endpoints with q and c.
Manuscript, audio, and film searches use /manuscripts/, /audio/, and /film-and-videos/ with trimmed result fields.
get_item_resources and compare_historical_sources fetch item metadata with fo=json.
No API key is required for the public LOC JSON/YAML API.
State values can be full names (California) or abbreviations (CA); both are normalized to LOC location facets.
MIT
Compare two LOC source records side by side using metadata fields only.
| Name | Required | Description | Default |
|---|---|---|---|
| itemIdOrUrl1 | Yes | First item ID or full loc.gov URL | |
| itemIdOrUrl2 | Yes | Second item ID or full loc.gov URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral context. It discloses that comparison uses 'metadata fields only,' but does not explain error handling, rate limits, or result format, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that conveys the core purpose without extraneous words. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with 2 parameters and no output schema, the description could be more complete by explaining what the comparison output looks like or any constraints (e.g., item source required). Missing these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds clarity ('full loc.gov URL') but does not significantly augment the schema meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('compare'), the resource ('LOC source records'), and the method ('using metadata fields only'). It distinguishes from sibling tools that focus on fetching or searching individual records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for comparing metadata, but provides no explicit guidance on when to use it versus alternatives (e.g., other comparison methods) or any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch raw OCR text from a supplied text URL (plain text).
| Name | Required | Description | Default |
|---|---|---|---|
| ocrTextUrl | Yes | URL to the OCR plain-text file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It only states the operation (fetch) but does not disclose behavioral traits like idempotency, error handling, or any side effects. The mention of 'plain text' is the only behavioral hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is efficient but could potentially include more utilitarian context without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly adequate. However, it omits details like expected return format (raw text string), size limits, or whether the fetch is synchronous. Adds no context beyond basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single parameter, the description adds minimal extra meaning (only confirming the output is raw OCR text). The schema already specifies the parameter is a URL to a plain-text file.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'raw OCR text from a supplied text URL', making the purpose unambiguous. It does not explicitly differentiate from sibling tools, but the function is distinct enough given sibling tools are mostly search-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or conditions. The description is purely functional without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a LOC item and return available digital resource files, images, and OCR links when present.
| Name | Required | Description | Default |
|---|---|---|---|
| itemIdOrUrl | Yes | Item ID, resource path, or full loc.gov item/resource URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only lists return types without mentioning side effects, authentication needs, rate limits, or error handling. The tool's read-only nature is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. However, it could benefit from structuring into multiple sentences for better readability, e.g., separating the action from the return types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description partially explains return values (files, images, OCR links) but does not specify format, structure, or what happens when resources are absent. It is adequate for a basic understanding but leaves gaps for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is fully documented. The description adds no new meaning beyond the schema's description of 'Item ID, resource path, or full loc.gov item/resource URL'. The description's mention of 'LOC item' reinforces the schema but does not extend it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch) and the resource (LOC item), and specifies the return types (digital resource files, images, OCR links). It distinguishes the tool's purpose from sibling tools that are more specialized or search-oriented, though it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like search tools or fetch_page_ocr_text. The description implies it is for fetching resources of a known item, but lacks when-not or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch metadata for a specific Library of Congress newspaper or item record.
| Name | Required | Description | Default |
|---|---|---|---|
| itemIdOrUrl | Yes | Item ID (e.g. 2014717546) or full loc.gov item/resource URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read operation ('fetch') but does not disclose additional behavioral traits such as authentication requirements, rate limits, or potential errors. It is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words. Every word contributes to purpose clarity, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is mostly complete. It could be improved by briefly noting what 'metadata' includes (e.g., title, date, location) but is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter has a clear description with an example. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches metadata for a specific Library of Congress newspaper or item record, using a specific verb ('fetch') and resource ('metadata'). It is distinct from sibling tools like search_historical_newspapers (search vs fetch specific item) and get_item_resources (resources vs metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage for fetching metadata by ID/URL, but provides no guidance on when not to use it (e.g., for searching or extracting text) or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Library of Congress audio records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 25) | |
| query | Yes | Search keywords |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavioral traits. It only states 'Search' implying read-only, but omits details about pagination, rate limits, response format, or whether it retrieves metadata or full recordings. This is minimal disclosure for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but underspecified. It conveys the basic purpose but does not earn its place by providing additional context that would aid tool selection or usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and any behavioral hints, the description is insufficient. It does not explain the nature of results, any sorting or filtering capabilities, or how it differs from sibling search tools beyond the collection name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters already described. The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Search) and the resource (Library of Congress audio records), distinguishing it from sibling tools that search other media collections. However, it lacks specificity about the type of audio records (e.g., recordings, oral histories) and could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of filters, query syntax, or comparisons to sibling search tools, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Library of Congress film and video records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 25) | |
| query | Yes | Search keywords |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states 'search... records' with no mention of read-only nature, pagination, response format, or any side effects. The schema provides the limit parameter, but behavioral context is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but under-specified. For a search tool with two parameters, more detail is needed. It sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage and no output schema, the description should provide additional context about searchable fields, result format, or typical use cases. It fails to differentiate effectively from sibling search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both 'query' and 'limit' parameters have descriptions in the schema. The description adds no additional meaning beyond the schema, but the baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches film and video records from the Library of Congress. It distinguishes from sibling tools that search other collections (audio, newspapers, maps, etc.), but lacks detail about the specific database or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The context of sibling tools implies it's for film/video, but no explicit conditions, prerequisites, or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search historical newspaper records from Chronicling America via the Library of Congress API.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20) | |
| query | Yes | Search keywords | |
| state | No | US state name or abbreviation to filter by | |
| dateEnd | No | End date (YYYY-MM-DD) | |
| dateStart | No | Start date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action and source, but does not disclose behavioral traits such as rate limits, authentication needs, whether it is read-only, or how it handles large queries. The description is too brief to adequately inform an agent of expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the main action and source. Every word is necessary and informative. It achieves conciseness without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters including filters and no output schema, the description does not explain what the tool returns, how results are formatted, or any pagination behavior. It lacks guidance on error handling or API specifics. A more complete description would mention return format or additional result details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all 5 parameters with descriptions, achieving 100% coverage. The tool description adds no additional context beyond the schema, so a baseline score of 3 is appropriate. The description does not explain the meaning or usage of any parameter beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches historical newspaper records from a specific source (Chronicling America via Library of Congress API). It uses a specific verb (search) and resource (historical newspaper records). While it distinguishes from sibling search tools by format (newspapers), it does not elaborate on the scope of the search (e.g., full-text vs. metadata) or how it differs from compare_historical_sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching historical newspapers, but provides no explicit guidance on when to use this tool vs. siblings like search_maps or search_manuscripts. There is no mention of alternatives, prerequisites, or when-not-to-use. The context is implied by the name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Library of Congress manuscript records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 25) | |
| query | Yes | Search keywords |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose behavioral traits such as pagination, return format, access restrictions, or rate limits. For a search tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. While concise, it could benefit from slightly more detail without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and no output schema, the description is minimally adequate but lacks context about result handling, filtering behavior, or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (query and limit) with descriptions, achieving 100% coverage. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and resource ('Library of Congress manuscript records'), clearly distinguishing it from sibling tools like search_maps or search_audio_recordings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as search_historical_newspapers or compare_historical_sources. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Library of Congress map records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20) | |
| query | Yes | Search keywords |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It does not disclose any behavioral aspects such as result format, pagination, sorting, or whether it supports boolean operators or filters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks important details for a tool with no annotations and no output schema. It is not optimally front-loaded with critical usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set (2 params, both described in schema), the description is still insufficient. It does not explain the nature of results, error conditions, or how to refine searches, leaving the agent without enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already defines 'query' and 'limit.' The description adds no additional meaning beyond 'search keywords' and 'max results.' Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'Library of Congress map records,' which differentiates it from sibling search tools targeting other media types like audio, film, or newspapers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'search_prints_and_photographs' or 'search_historical_newspapers.' The description does not mention use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Library of Congress prints and photographs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20) | |
| query | Yes | Search keywords |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses no behavioral traits such as authentication, rate limits, or pagination behavior. The 'search' verb implies a read operation, but no further details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it under-specifies the tool's behavior. While it avoids unnecessary text, it lacks important details, making it merely adequate rather than concise in a helpful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about return format, error handling, or search behavior. It is incomplete for practical use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters. The description adds no additional semantic information beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches prints and photographs from the Library of Congress, using the verb 'Search' and specifying the resource. However, it does not differentiate from sibling tools like search_audio_recordings or search_maps, which could be confused if not for the explicit resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention that it is specific to prints and photographs, nor does it provide context for exclusion or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct resource type (audio, film, newspapers, manuscripts, maps, prints) or a specific action (compare, fetch, get), with no overlapping purposes. An agent can easily select the right tool based on the resource or operation needed.
All tool names follow a consistent verb_noun pattern in snake_case, with verbs like 'search', 'get', 'fetch', 'compare' clearly indicating the action. The naming is uniform and predictable across the set.
With 10 tools, the server covers the major historical resource categories and common operations without being overwhelming or too sparse. The count is well-scoped for the purpose of investigating historical materials.
The tool set provides search and retrieval for major LOC collections (audio, film, newspapers, manuscripts, maps, prints) plus comparison and OCR features. It lacks coverage for some categories like books or serials, but these are reasonable omissions for a historical investigator focused on primary sources.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agentic search over your Dewey document collections from any MCP-compatible client.
BGG MCP provides access to the BoardGameGeek API through the Model Context Protocol, enabling retr…
Official MCP connector for Legalize: read and search its whole open corpus, at any point in time.
Access U.S. congressional data - bills, votes, members, committees - via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jay1234624/historical-investigator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
