Skip to main content
Glama
tobbaz

kb-newspapers-mcp

by tobbaz

search_newspapers

Find mentions in digitized Swedish historical newspapers from the 1600s to 1910 via full-text OCR search. Use wildcards for spelling variants to get page-level results with snippets and image links.

Instructions

Search digitized Swedish historical newspapers (17th century to circa 1908–1910).
Performs OCR full-text search and returns page-level hits with highlighted snippets and image links.

Historical Search & OCR Strategies:
- Fraktur / Gothic Print: 17th to late 19th-century newspapers were mostly printed in Fraktur/blackletter.
  OCR engines frequently confuse similar glyphs (e.g. long 's' [ſ] misread as 'f', 'S', or 'l'; 'c' for 'e'; 'rn' for 'm').
- Historical Spelling & Wildcards: Use wildcard '*' or Boolean 'OR' to catch spelling variations
  (e.g. 'Carlscrona OR Karlskrona', 'Gustaf OR Gustav', 'Linné OR Linnaeus', or stem wildcards like 'Söder*').
- Two-Stage Workflow:
    1. Use this tool ('search_newspapers') for initial discovery of dates, issues, and page numbers.
    2. If snippets are cut off or you need surrounding sentences (e.g. destinations, causes of death, full names),
       call 'search_in_issue(package_id=..., query=...)' on the matched issue to retrieve complete verbatim quotes.
    3. Always present the 'images.preview_width' link so users can visually verify the scanned page if OCR is unclear.

Args:
    query: Search term or phrase in Swedish/English (e.g. 'ångfartyg', 'Carl von Linné', 'brand i Karlskrona').
    from_date: Start date in 'YYYY-MM-DD' format or simply year 'YYYY' (e.g. '1850').
    to_date: End date in 'YYYY-MM-DD' format or simply year 'YYYY' (e.g. '1899').
    newspaper: Filter by specific newspaper title (e.g. 'Aftonbladet', 'Dagens Nyheter', 'Post- och inrikes tidningar', 'Göteborgsposten').
    sort_by: Sort order: 'relevance' (most relevant), 'date_asc' (oldest first), or 'date_desc' (newest first).
    limit: Number of results to return per page (1-100, default 20).
    offset: Zero-based starting index for pagination (default 0).
    max_snippets: Maximum number of text snippets to include per newspaper page (default 5).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
offsetNo
sort_byNorelevance
to_dateNo
from_dateNo
newspaperNo
max_snippetsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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 transparently discloses the tool's limitations (OCR errors in Fraktur text, possibly cut-off snippets) and prescribes mitigations (present image links, use search_in_issue for verification). It does not mention rate limits or auth, but the OCR caveat and workflow guidance provide meaningful behavioral context beyond what the schema shows.

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 description is long but earns its length: the OCR background and examples are essential for effective use of this historical search tool on a difficult domain. The structure is logical (purpose → strategy → workflow → args). It could be slightly trimmed, but the density of actionable information is high and there's no filler.

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?

For a search tool with this complexity (OCR issues, historical spelling, date handling, pagination), the description is thorough. It explains return values implicitly (page-level hits with snippets and image links), gives remediation steps when OCR is unclear, and covers all parameters. The presence of an output schema reduces the need for describing returns, and the description covers the remaining operational context well.

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 0%, so the description must compensate. It explains each parameter with concrete examples (query: 'ångfartyg', 'brand i Karlskrona'; from_date/to_date: 'YYYY-MM-DD' or 'YYYY'; newspaper: 'Aftonbladet'; sort_by options and limit/offset/max_snippets semantics). It adds value by explaining the date formats and giving example values, which the JSON schema alone does not provide.

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

Purpose5/5

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

The description clearly states the tool's purpose: searching digitized Swedish historical newspapers with OCR full-text search, returning page-level hits with snippets and image links. It distinguishes itself from siblings by explicitly naming search_in_issue as the follow-up tool for complete verbatim quotes, making its role in the workflow clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance, including the two-stage workflow (use this tool for initial discovery, then search_in_issue for full quotes). It also advises on OCR-specific strategies like using wildcards and Boolean OR for spelling variations, which is essential for an agent to know when to use this tool effectively.

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