Skip to main content
Glama
german-archives-mcp
by ianderso

rlp_image

Idempotent

Downloads one APERTUS register page from Rheinland-Pfalz as a JPG so you can read and cite it without downloading the whole volume.

Instructions

Download one page of an APERTUS register (Rheinland-Pfalz), so it can be read.

The archive serves a volume only as one PDF: a volume's first page costs a download of the whole (tens of MB, up to a minute), kept on disk for later pages. Read the page before citing it. page is the PDF's page, not the number written on the page. Saves a new .jpg or .jpeg file, never returned inline: not hidden, not under ~/Library, and inside the operator's download folder when one is set. Cite by the citation returned.

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": {
      "item": "<item>",
      "destination": "<destination>",
      "page": "<page>"
    },
    "name": "rlp_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
itemYesAn rlp_search unit's `item` (a GUID), its permalink, or its signature, e.g. 'Best. 657,349 Nr. 4'.
pageYesWhich page of the volume's PDF, 1-based.
destinationYesAbsolute path of a new .jpg file, e.g. '/path/to/images/657-349-4-p3.jpg'. 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.3/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing cost (whole volume, tens of MB, up to a minute), on-disk caching that makes later pages cheap, that a new file is written and nothing is overwritten, and the path rules (not hidden, not under ~/Library, inside the operator download folder when set). It also states the output is a file plus a returned `citation`, never inline content.

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?

Front-loaded with the action in the first sentence, then cost, file semantics, and citation guidance in a logical order. Slightly dense and line-wrapped, but every sentence carries information the agent needs.

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?

With no output schema, the description carries the return contract itself: a new .jpg path plus a `citation` to cite by, and it explains the expensive first-page download that later pages benefit from. Nothing an agent needs in order to call this correctly or interpret the result is missing.

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?

With 100% schema coverage the baseline is 3, and the description adds real meaning by warning that `page` is the PDF's page, not the number printed on the page, a distinction the schema only implies. The destination non-overwrite rule restates what the schema already says, so it does not add further value.

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?

Names a specific verb and resource: download one page of an APERTUS register (Rheinland-Pfalz). The archive qualifier implicitly separates it from the hessen/labw/nrw image siblings, but no sibling is named explicitly and the description does not state it is the Rheinland-Pfalz counterpart of those tools.

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?

Gives clear usage context: obtain a page to read, and read it before citing, with the `item` sourced from an rlp_search unit. It does not spell out the ordering as a prerequisite (search first, then image) or state when a different archive tool should be chosen instead.

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