geldersarchief-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GA_CACHE_DB | No | Path to the local SQLite observation cache. | <GA_DATA_DIR>/cache.sqlite |
| GA_DATA_DIR | No | Base directory for data storage. | data |
| GA_USER_AGENT | No | User-Agent string containing your project URL or contact address, as requested by Open Archieven for public use. | |
| GA_DOWNLOAD_DIR | No | Directory where downloads are stored. | <GA_DATA_DIR>/downloads |
| GA_OCR_LANGUAGE | No | OCR language data used by the resolver. | nld |
| GA_OCR_EXECUTABLE | No | OCR executable used by the resolver. | tesseract |
| GA_BROWSER_HEADLESS | No | Whether the browser runs headless. | true |
| GA_RESOLVER_MAX_SCANS | No | Maximum number of scans the resolver may inspect. | 24 |
| GA_MAX_IMAGE_DOWNLOADS | No | Maximum number of concurrent image downloads. | 2 |
| GA_BROWSER_HTTP_TRANSPORT | No | Use HTTP transport with controlled TLS via the OS trust store for viewer research and browser fallbacks. | false |
| GA_MAX_CONCURRENT_REQUESTS | No | Maximum number of concurrent requests. | 2 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_actsB | Search Gelders Archief acts in Open Archieven; date filters the event date. Multiple records remain separate; number_found counts API person hits. Use record_id for subsequent calls. next_start enables pagination. |
| get_recordC | Get a gld: record with act number, act/event dates, source and relatives. |
| inspect_registerB | Discover all scan references; return the proven total and a paginated scan list. start is one-based. Missing batches/unknown totals are errors, never complete results. |
| resolve_act_scanA | Resolve an act using exactly one of record_id/source_url; date means act date. Default: explicit archive metadata only, with no OCR or image downloads. Optional installed local readers return bounded evidence and candidates. AMBIGUOUS/PROBABLE must not be treated as a confirmed act. |
| download_scanA | Download an explicitly selected one-based scan with SHA256 and local provenance. Provide exactly one record_id/source_url. Selection does not verify act identity. Files are exposed through resource_uri/provenance_uri, not inline base64 JSON. |
| download_actB | Resolve and download an act; original means unchanged viewer-download bytes. FOUND downloads its bound scans. Uncertain results return files=[]. A supplied scan_sequence explicitly selects a scan (status SELECTED). allow_probable permits a PROBABLE download while preserving that status. No archive-master claim or silent first-record/candidate selection is made. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Most tools have distinct purposes (search, get, inspect, resolve, download), but resolve_act_scan and download_act overlap since download_act also resolves, and download_scan vs download_act both download scans. Descriptions provide enough guidance to differentiate them, keeping this a minor issue.
All six tools follow a consistent snake_case verb_noun pattern: get_record, search_acts, inspect_register, resolve_act_scan, download_scan, download_act. The convention is predictable and readable throughout.
Six tools is well-scoped for a focused archival/genealogy resolution workflow. Each tool targets a distinct stage (search, retrieve, inspect, resolve, download) without redundancy bloat.
The surface covers the full discovery-to-download lifecycle: searching acts, fetching records, inspecting registers, resolving acts to scans, and downloading scans/acts. Minor gap in that there's no explicit listing of collections/registers beyond inspect_register, but core workflows are covered.