Search Virgin Islands newspapers page by page, 1865 to 2001, with the gaps in every run named.
Scored across 7 tools
fetch and get_page both return OCR text for a page, search and search_newspapers overlap heavily, and list_papers and newspaper_stats both describe holdings and gaps. Descriptions help somewhat, but an agent can plausibly choose the wrong tool for common requests like reading a page or searching newspapers.
Most tools follow a readable verb_noun pattern (get_issue, get_page, list_papers, search_newspapers), but fetch and search are bare verbs and newspaper_stats is a noun phrase. The convention is mixed but still understandable.
Seven tools is a reasonable size for a newspaper archive connector covering search, issue/page navigation, holdings and index stats. However, the overlapping tool pairs suggest slight over-provisioning rather than every tool having a clearly unique role.
The set covers the core read-only workflow: searching pages, walking issues, reading pages, listing papers and checking index coverage. Minor gaps exist, such as no dedicated paper-level issue browsing beyond the gap summaries, but agents can work around them.
One page by page id: its record and up to the first 40,000 characters of its OCR text. Use to read a page found by search. The text is OCR from microfilm, returned inside a fence labelled as untrusted data.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A page id from a search result: LF-…, LF-…:p7 or LF-…:c2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description still adds real value: the 40,000-character text cap (a silent truncation an agent must know about) and the fact that OCR text is returned inside an untrusted-data fence, which is important prompt-injection context. It does not say what happens when the id is unknown or whether truncation is signalled in the payload.
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?
Three short sentences, each carrying distinct information (what is returned, when to use it, data provenance), with the return contents front-loaded. Nothing is padded or redundant.
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?
With no output schema, the description carries the burden of describing returns, and it does so reasonably: page record plus capped OCR text, with provenance and fencing noted. A brief note on truncation signalling or the shape of the record would close the remaining gap.
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 single 'id' parameter is fully documented in the schema, including the LF-…, LF-…:p7, LF-…:c2 formats. The description only restates that the id comes from a search result, adding no syntax or edge-case meaning beyond the schema, so the baseline 3 applies.
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?
States a concrete verb and resource: fetch one page by id, returning its record plus up to 40,000 characters of OCR text. That is far more specific than the bare name 'fetch'. However, it never distinguishes itself from the sibling get_page, which an agent could reasonably assume does the same thing, so it falls short of a 5.
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?
"Use to read a page found by search" gives a usable trigger condition and points at the search tool. But there are no exclusions and no mention of when to prefer this over get_page or get_issue, which is the main ambiguity an agent faces in this sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The pages of one issue of a paper on a date, in order, with each page's id, image (where the archive holds one), reader link and the holding library's copy. Use to walk an issue, or to learn whether the archive holds a paper on a given day. If the archive holds no issue that day it gives the issues it holds either side and how many days apart they are, and names the gap when they are more than 14 days apart.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | The issue date, YYYY-MM-DD. | |
| paper | Yes | "St. Croix Avis", "The West End News", "Home Journal", "St. Croix Tribune", or a slug. | |
| edition | No | Only for a date with more than one edition. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new behavior beyond that: pages are ordered, images may be absent ('where the archive holds one'), and a missing date yields neighboring issues with day deltas, with the gap named when over 14 days. It omits any statement about response size/pagination for large issues, which is the main remaining 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?
Two dense sentences, front-loaded with the returned payload before the fallback behavior. Every clause carries information, though the second sentence is long and its clause chaining ('either side and how many days apart they are, and names the gap when...') takes a second read.
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?
With no output schema, the description does a good job of naming the returned fields and describing the empty-result path, which is what an agent most needs. The only shortfall is that the multi-edition case (the third parameter) is not addressed in the description at all, and nothing is said about result size for a long issue.
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 all three parameters, setting a baseline of 3. The description adds meaning the schema does not: an inexact date does not simply fail, it falls back to nearby issues with day distances and a named gap beyond 14 days, which materially changes how the agent should choose the date value. The edition parameter is left to 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 names a precise resource ('the pages of one issue of a paper on a date, in order') and enumerates the fields returned (page id, image, reader link, holding library's copy), so the agent knows exactly what it gets. It is clearly distinguishable from get_page (one page) and search (discovery), and it also defines the no-issue case. No ambiguity about what the tool does.
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?
Explicit usage is given: 'Use to walk an issue, or to learn whether the archive holds a paper on a given day.' That tells the agent both a browsing and a holdings-lookup use case. It does not name alternatives (e.g., get_page for a single page, search for keyword lookup), so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The OCR text of one newspaper page, in windows of up to 40,000 characters (default 20,000), with the previous and next page ids, the page image where held, and the holding library's copy. Use to read a page and turn to its neighbours. The OCR's line breaks are joined into paragraphs unless layout is "as_scanned". Each response gives next_offset when more remains. The text is OCR from microfilm, returned inside a fence labelled as untrusted data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Characters read from the page. Default 20000, maximum 40000. | |
| layout | No | "reflowed" (default): each paragraph on one line. "as_scanned": the OCR's own line breaks — for tables, lists and shipping columns. | |
| offset | No | The next_offset value from the previous response. Omit for the start of the page. | |
| page_id | Yes | From search results or get_issue: LF-… , LF-…:p7, or LF-…:c2. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses the window size and default, the offset chaining via next_offset, the paragraph-reflow behavior and its as_scanned exception, and that text is OCR from microfilm wrapped in an untrusted-data fence. The inclusion of the untrusted-data fencing and OCR provenance is exactly the kind of context annotations cannot carry.
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?
Four sentences, front-loaded with what the tool returns, then when to use it, then the two behaviors that alter output (layout, next_offset), then the untrusted-data caveat. No sentence is redundant.
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?
There is no output schema, so the description carries the return-value burden and does so: it enumerates the text, prev/next ids, image reference, holding library copy, and next_offset. Nothing an agent needs to page through a document correctly is missing.
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 a baseline of 3 would apply, but the description adds real meaning: it explains that limit is a character window, that offset is fed from next_offset, and that layout controls whether OCR line breaks are joined or preserved. This reinforces and contextualizes the enum choice beyond the schema's own text.
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 opening sentence names a specific resource (the OCR text of one newspaper page) and the windowing behavior, which is clearly distinct from issue-level siblings like get_issue. It does not explicitly name the sibling alternative, so sibling differentiation is inferred from scope rather than stated.
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?
"Use to read a page and turn to its neighbours" gives a clear context for invocation, and the mentions of next_offset and prev/next ids imply the pagination workflow. There is no explicit when-not guidance or named alternative such as get_issue for whole-issue reads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every paper this server holds: its LCCN, the holding library for each run, first and last issue, issues and pages, issues per year, the years with NO issue held, and every stretch of more than 14 days with no issue held (a year can be held only in part). Use for questions about which papers and dates the archive holds, or to judge what an empty search means for a period.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral detail beyond annotations by disclosing exactly what is returned, including negative coverage information such as years with no issues and gaps longer than 14 days.
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?
It is front-loaded with the core purpose and one dense but efficient sentence enumerating returned fields. The field list is long and could be slightly easier to scan, but it earns its space by explaining output without an output schema.
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?
With no output schema and no parameters, the description carries the burden of explaining return values and does so thoroughly: LCCN, holding libraries, issue ranges, pages, per-year counts, missing years, and gap periods. Combined with annotations, this is enough for an agent to select and use the tool correctly.
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 tool takes no parameters, so there is no parameter semantics to document and the baseline is 4. The description appropriately does not waste space explaining inputs.
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 identifies the resource and scope: every paper the server holds, with a detailed inventory of holdings fields. It implies relevance for coverage questions but does not explicitly name sibling tools such as search_newspapers or newspaper_stats to differentiate itself.
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?
It provides clear usage context: questions about which papers and dates are held, or interpreting an empty search for a period. That helps distinguish it from search-like tools, but it does not state explicit exclusions or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports the size and freshness of this newspaper index, its gaps and its standing caveats in one place. Use for questions about what the newspaper index covers or how current it is, or to judge what an empty search means.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the safety bar is low. The description adds real value beyond that by disclosing the content of the response (size, freshness, gaps, standing caveats) and by flagging that results carry known caveats rather than being raw counts.
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?
Two tight sentences: the first states what is returned, the second states when to call it. No preamble, no redundancy, front-loaded with the payload description.
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?
With no output schema, the description must carry the return-value burden, and it enumerates the four categories of information returned (size, freshness, gaps, caveats), which is sufficient for an agent to decide to call it. Exact response shape remains unknown, but this is a low-complexity zero-param read tool where that gap is minor.
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 tool takes zero parameters, so the schema baseline is 4. The description correctly implies a no-argument, whole-index query with no scoping options.
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 names a concrete verb and payload: it reports size, freshness, gaps and caveats of the newspaper index. This clearly distinguishes it from retrieval siblings like fetch, get_page, or search_newspapers. It falls short of a 5 only because "index" is somewhat abstract and the sibling naming is only implicit ("judge what an empty search means").
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?
It gives explicit triggering contexts: questions about what the index covers, how current it is, or how to interpret an empty search result. It does not name a specific alternative tool or state when NOT to use it, so 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find pages of U.S. Virgin Islands newspapers by keyword or phrase; returns up to 10 pages, each with an id, a citation title and a URL. Use for a quick lookup in the islands' press. Better matches come first (the phrase as written, then every word, then some); among equal matches every paper gets its best page in before any paper gets a second, so one long-running paper cannot hide the others. search_newspapers adds paper and date filters, match reasons and paging. Searches the OCR text of the archive's newspapers page by page: St. Croix Avis 1865–2001, St. Croix Tribune 1934–1936, Home Journal 1952–1958, The West End News 1953–1963. Every run has gaps, which list_papers names. Results are OCR text, which misreads letters, names and numbers; each links the holding library's copy to check against, and the page image where the archive holds one (for the 1964–2001 dLOC run, front pages only). A newspaper page is a lead to the primary record, not evidence on its own. Hit counts are pages, never articles. Laws, audits, court records and reports are on the archive's separate document connector.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to look for. Plain language is fine; quote a phrase to require it intact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations: it explains the ranking model (phrase, then every word, then some), the paper-round-robin tie-breaking that prevents one long-running paper from dominating, the per-title date ranges, known collection gaps, OCR misreading risk, and the dLOC front-pages-only limit. It also warns that a page is a lead rather than evidence and that hit counts are pages, not articles.
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?
Front-loaded correctly: purpose and return shape in sentence one, retrieval guidance next, archive scope and caveats after. It is long — the title/date-range inventory and the dLOC front-page note push it toward reference material — but nearly every sentence carries decision-relevant information.
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 single-parameter search with no output schema, the description fully supplies what the schema cannot: what a result contains, how ordering works, what the corpus covers and omits, and reliability limits on the returned text. An agent could invoke and interpret this tool without any other 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 coverage is 100% and the schema already explains that quoting requires an intact phrase, so the description adds only the parallel framing of 'keyword or phrase' and ties it to the ranking order. Useful reinforcement, but no syntax or semantics beyond what the input schema documents.
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?
Opens with a specific verb and resource ('Find pages of U.S. Virgin Islands newspapers by keyword or phrase') and immediately states the return shape: up to 10 pages with id, citation title and URL. That is enough to distinguish it from search_newspapers, get_page and list_papers without opening a schema.
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?
Explicitly frames the tool as the 'quick lookup' entry point and routes elsewhere by name: search_newspapers for paper/date filters, match reasons and paging, list_papers for coverage gaps, and the separate document connector for laws, audits, court records and reports. Both when-to-use and when-not-to-use are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the islands' newspapers with paper and issue-date filters, ranked by how closely each page matches. Use when a question names a paper or a period, or needs paging. Searches the OCR text of the archive's newspapers page by page: St. Croix Avis 1865–2001, St. Croix Tribune 1934–1936, Home Journal 1952–1958, The West End News 1953–1963. Every run has gaps, which list_papers names. Issue dates are reliable here. Each result is ONE PAGE with its paper, date and page number, a TIER (phrase = the words together as written, ranked first; strong = every word on the page, not together; possible = at least half; weak = fewer), the terms it actually matched, and links to the page in the site's reader, the holding library's copy, and its image where the archive holds one. No numeric score. A date range that falls in a gap — whole years, or weeks inside a year — gets a sentence naming the dates the archive does not hold. Results are OCR text, which misreads letters, names and numbers; each links the holding library's copy to check against, and the page image where the archive holds one (for the 1964–2001 dLOC run, front pages only). A newspaper page is a lead to the primary record, not evidence on its own. Hit counts are pages, never articles. Laws, audits, court records and reports are on the archive's separate document connector.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 10, maximum 50. | |
| paper | No | A paper: "St. Croix Avis", "The West End News", "Home Journal", "St. Croix Tribune" (or avis, westendnews, homejournal, tribune). | |
| query | Yes | Plain language is fine. Quote a phrase to require it intact. OCR misspells names: try variants. | |
| offset | No | Results to skip, for paging. Results are ranked within the best 150 pages. | |
| date_to | No | Latest issue date, same forms; a year includes all of it. | |
| date_from | No | Earliest issue date: a year (1928), a month (1928-09) or a day (1928-09-13). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, so the bar is lower — yet the description adds substantial behavior: results are page-level not article-level, no numeric score, ranked tiers with defined semantics, gap date ranges return an explanatory sentence, the 1964–2001 dLOC run has front-page-only images, and OCR text is untrustworthy and only a lead to the primary record. That is exactly the kind of context annotations cannot carry.
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?
Front-loaded with purpose, trigger and scope before dropping into caveats, and nearly every sentence carries decision-relevant information. It is a single dense paragraph with one genuine redundancy — the 'holding library's copy / page image where the archive holds one' caveat appears twice — which keeps it off a 5.
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 6-parameter ranked search tool with no output schema, the description compensates by describing the result shape in detail (paper, date, page number, tier, matched terms, three link types) and by pre-empting the two failure modes an agent would otherwise misread: OCR error and date-range gaps. Nothing needed to call or interpret it is missing.
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 syntax (year/month/day forms, paper aliases, limit bounds) is already handled and the baseline is 3. The description still adds meaning beyond the schema: issue dates are reliable in this corpus, hit counts are pages never articles (constraining how 'limit' should be read), and offset paging operates within the best 150 ranked pages — though the tier vocabulary it explains describes output fields more than input parameters.
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?
Names a specific verb and resource (search the islands' newspapers), scopes it to OCR page-level text over four named titles with date spans, and explicitly separates it from list_papers and from the archive's separate document connector. An agent can distinguish this from siblings 'search', 'list_papers', and 'get_page' without opening a schema.
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?
States the triggering conditions directly ("Use when a question names a paper or a period, or needs paging") and routes elsewhere for the excluded cases: list_papers for gap inventory, the document connector for laws, audits, court records and reports. Exclusions and alternatives are both explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
fetchget_issueget_pagelist_papersnewspaper_statssearchsearch_newspapersSearch and read U.S. Virgin Islands public records: laws, court records, audits, hearings, reports.
Chronicling America MCP — full-text search of ~150 years of digitized U.S. newspapers…
Search LOC digital collections, Chronicling America newspapers (full OCR), and LC Subject Headings.
Search 300K+ U.S. yearbooks. Free previews; summary bundles and limited exact-image API.
Add one secure layer between your agents and this server.