Skip to main content
Glama
polish-archives-mcp

polish-archives-mcp

by ianderso

swa_scan

Idempotent

Download a full-size archival scan from Szukaj w Archiwach to a specified new .jpg file using its scan hash, enabling offline genealogy research.

Instructions

Download one full-size scan (about 3500 px) from Szukaj w Archiwach's photo host.

The unit page itself is behind a bot check: a person opens it in a browser, reads the Sygnatura, and takes each scan's hash from its image address. The scan is written to destination, never returned inline: a new .jpg or .jpeg, not hidden, not under ~/Library, and inside the operator's download folder when one is set. Cite it by the Sygnatura and scan number, not by this address.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "hash": "<hash>",
      "destination": "<destination>"
    },
    "name": "swa_scan"
  }
}

Input Schema

NameRequiredDescriptionDefault
hashYesThe scan's 64-character hex name, read from the unit page in a browser.
destinationYesAbsolute path of a new .jpg file. The directory must exist and the file must not: nothing is overwritten.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true), the description discloses that the scan is written to disk rather than returned inline, that the file must be new, and quirky placement constraints (not hidden, not under ~/Library, inside the operator's download folder when one is set). It also discloses the human-in-the-loop bot-check requirement, which 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the disk-write behavior are front-loaded, and each sentence carries information about prerequisites, destination, or citation. It is somewhat verbose in repeating destination constraints that the schema already encodes, which costs it a point.

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?

With only two required parameters, no output schema, and a file-writing side effect, the description covers what an agent most needs: it is not returned inline, where it lands, and how to refer to it afterward. It omits any mention of failure modes when the bot check or hash lookup fails, but that is a small residual gap.

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 both parameters are already documented as a 64-character hex name and an absolute path to a non-existent .jpg. The description restates those constraints ('new .jpg or .jpeg', 'nothing is overwritten') and adds the useful note to cite the result by Sygnatura and scan number rather than the address, but adds no new syntax or format detail.

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 names a specific verb and resource: download one full-size scan (~3500 px) from Szukaj w Archiwach's photo host. That is unambiguous about what the tool produces. It does not explicitly position itself against the sibling search tools, but their names suggest different resources, so the gap is minor.

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 clearly states the prerequisite workflow: the unit page is behind a bot check, so a human must open it in a browser and read the Sygnatura and per-scan hash, which is then passed in. That is real when-and-how guidance rather than a bare 'use this to download'. It stops short of naming any alternative tool or when not to use it.

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