Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@swedish-portrait-archive-mcp Search for portraits of Carl Kastengren, born 1826"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
swedish-portrait-archive-mcp)A Model Context Protocol (MCP) server for searching and retrieving historical Swedish portraits, biographies, and printed matrikel sources from Svenskt Porträttarkiv (Swedish Portrait Archive).
Svenskt Porträttarkiv contains over one million portraits scanned from printed Swedish biographical collections, military rolls, professional directories, and anniversary publications from the 19th and 20th centuries.
Historical Portrait Search (search-portraits): Search by first name, last name, birth/death year, birth parish/county, occupation, and free-text queries.
Biographical Details & Transcriptions (get-portrait-details): Fetch full biographical texts, printed book references, Swedish Death Index cross-references (Sveriges Dödbok ID), and formatted genealogical citations.
Direct Image Access (get-portrait-image): Generate direct URLs to high-resolution portrait scans (JPEG) and online archive records.
Genney Compatibility: Produces ready-to-paste citation blocks designed for Swedish genealogical software (Genney).
Related MCP server: KB MCP Server
Svenskt Porträttarkiv is operated as a volunteer, non-profit community initiative founded by Omar Henriksson. To ensure respectful, fair, and responsible integration, this MCP server adheres to strict ethical guidelines:
Strict Rate Limiting (RequestQueue): All outgoing network requests are queued sequentially with an enforced delay of at least 400 ms (+ randomized jitter) between requests.
Transparent User-Agent: Every request identifies itself clearly:
User-Agent: SwedishPortraitArchiveMCP/1.0 (+https://github.com/tobbaz/swedish-portrait-archive-mcp)No Bulk Scraping: The tools operate exclusively on-demand for targeted genealogical queries. The server does not support mass harvesting or mirroring of the archive.
Attribution & Licensing:
Individual portraits and biographical texts are generally licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).
The composite archive collection is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0).
Every search result and detail query provides direct links back to the original entry at https://portrattarkiv.se/details/{id}.
search-portraitsSearches the archive for portraits matching given genealogical parameters.
Parameter | Type | Description |
|
| Given name (e.g. |
|
| Surname (e.g. |
|
| Birth year (e.g. |
|
| Death year (e.g. |
|
| Parish, town or county of birth |
|
| Occupation or title (e.g. |
|
| Workplace or place of residence |
|
| Free-text search across all metadata |
|
| Results limit (default: 20, max: 100) |
|
| Pagination offset |
get-portrait-detailsRetrieves full details for a portrait record.
Parameter | Type | Description |
|
| Portrait unique ID (e.g. |
Returns transcribed biographies, source collections/books, Sveriges Dödbok ID, and a Genney-formatted citation.
get-portrait-imageReturns direct links to the high-resolution JPEG image and archive web page.
Parameter | Type | Description |
|
| Portrait unique ID |
Node.js 18+ or 20+
npm
git clone https://github.com/tobbaz/swedish-portrait-archive-mcp.git
cd swedish-portrait-archive-mcp
npm install
npm run buildnpm testAdd the server to your mcp_config.json (or claude_desktop_config.json):
{
"mcpServers": {
"swedish-portrait-archive": {
"command": "node",
"args": [
"/absolute/path/to/swedish-portrait-archive-mcp/build/index.js"
]
}
}
}Code: Released under the MIT License.
Archive Data & Portraits: Provided by Svenskt Porträttarkiv under Creative Commons licenses (CC BY-SA 4.0 / CC BY-NC-SA 4.0).
Retrieve comprehensive metadata, transcribed biography, book citation, vital statistics, and Genney-ready citation snippet for a specific portrait ID.
| Name | Required | Description | Default |
|---|---|---|---|
| portraitId | Yes | The unique portrait identifier (e.g. "sj9PGLAlnmUAAAAAABlg4w") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. The verb 'Retrieve' signals a read-only operation, and the description discloses the returned content categories, including the Genney citation format. It does not cover error/null behavior, but that is a minor gap for a simple get-by-ID tool.
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?
One compact, front-loaded sentence with no filler. It names the action and the full set of returned data efficiently. Every phrase adds useful signal.
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 one-parameter read tool with no output schema, the description is nearly complete: it names the resource, the key, and the returned content. It could explicitly route users to search-portraits when no ID is known, but that is not essential for correct invocation.
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 parameter portraitId is already fully described in the input schema with an example, and schema description coverage is 100%. The tool description adds no additional parameter-level meaning, so the baseline score of 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?
The description uses a specific verb, 'Retrieve,' and a specific resource, 'portrait details,' keyed by a portrait ID. It also enumerates the payload (metadata, biography, citation, vital statistics, Genney-ready snippet), which clearly distinguishes it from the sibling get-portrait-image tool.
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?
The description makes clear it applies to a specific known portraitId and is meant for fetching detail records. It does not explicitly state when to use search-portraits instead or exclude image retrieval, but the intended context is implied well enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get direct high-resolution image URL (JPEG) and web page links for a portrait by its identifier.
| Name | Required | Description | Default |
|---|---|---|---|
| portraitId | Yes | The unique portrait identifier (e.g. "sj9PGLAlnmUAAAAAABlg4w") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only lists the returned items ('image URL' and 'links') but does not disclose any behavioral traits such as read-only status, potential errors, rate limits, or whether the URL is temporary or direct. No safety or side-effect information is given.
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?
The description is a single clear sentence with no filler. It front-loads the primary action and outputs, and every word earns its place.
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 simple one-parameter tool, the description states the return types ('image URL' and 'web page links'), but lacks detail on the response structure (e.g., whether it is a single URL or an object with multiple links), error conditions, or any additional fields. No output schema exists, so the description is expected to cover return semantics more fully. This is adequate but leaves ambiguity.
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 input schema already describes portraitId fully with an example. The description's phrase 'by its identifier' adds little beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate; the description does not contribute significant extra parameter meaning.
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 uses a specific verb 'Get' and names the exact outputs ('direct high-resolution image URL (JPEG) and web page links') and input ('by its identifier'). This clearly distinguishes it from sibling tools like search-portraits and get-portrait-details, even without naming them.
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?
No guidance is given on when to use this tool versus alternatives. It does not state prerequisites (e.g., 'use after search-portraits to obtain an identifier') or explain when to prefer get-portrait-details instead. The intended usage is only implicit through the phrase 'by its identifier'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Svenskt Porträttarkiv (Swedish Portrait Archive) for historical portraits by name, birth/death year, birth place, occupation, or free text. Returns matched individuals with ID, book source, biographical snippet, and links.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Offset index for pagination (default: 0) | |
| limit | No | Maximum number of results to return (default: 20, max: 100) | |
| query | No | General free-text search across all indexed metadata | |
| lastName | No | Surname/family name to search for (e.g. "Kastengren" or "Lindahl") | |
| birthYear | No | Year of birth (e.g. 1826 or "1826") | |
| deathYear | No | Year of death (e.g. 1904 or "1904") | |
| firstName | No | Given/first name to search for (e.g. "Emanuel" or "Carl August") | |
| birthPlace | No | Parish, town or county of birth (e.g. "Säbyholm", "Everöd", "Helsingborg") | |
| occupation | No | Occupation, profession or title (e.g. "Veterinär", "Löjtnant", "Bokhållare") | |
| employmentPlace | No | Place of employment or residence |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose the data source and result shape (matched individuals with ID, book source, biographical snippet, and links), but it leaves unspecified behaviors such as how multiple filters combine, whether an empty query is allowed, and how pagination works.
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 sentences with no filler: the first states the action and criteria, the second summarizes the return values. Every clause carries information and the description avoids simply restating the tool name.
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?
The description covers core purpose and output, and the schema documents all 10 parameters, so a basic invocation is feasible. However, because there is no output schema and no annotations, the description leaves gaps around filter combination semantics, empty-query behavior, and pagination interactions.
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?
Input schema coverage is 100% and every parameter already has a meaningful description, so the schema does the heavy lifting. The prose adds a useful category-level overview of the search criteria but does not need to repeat parameter-level details.
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 uses a specific verb ('Search'), names the resource ('Svenskt Porträttarkiv'), and enumerates the search dimensions (name, birth/death year, birth place, occupation, free text). It clearly describes what results come back, but it does not explicitly differentiate itself from the sibling tools get-portrait-details and get-portrait-image.
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?
The intended use is implied: call this tool to search the portrait archive for matching individuals, presumably before fetching details or images. However, the description never states when not to use it or names the alternatives, so routing to siblings is left to inference.
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.
v1.0.0get-portrait-detailsget-portrait-imagesearch-portraitsScored across 3 tools
Each tool addresses a distinct stage of the workflow: searching for individuals, retrieving detailed metadata for a selected portrait, and fetching the image URL. There is no overlap or ambiguity between these three operations.
All tool names follow a consistent lowercase hyphenated verb_noun pattern: search-portraits, get-portrait-details, get-portrait-image. The pattern is predictable and uniform across the set.
Three tools is a perfectly concise scope for this server: search, retrieve details, and retrieve image. Each tool has a clear purpose and none feel redundant or missing.
The tool set covers the full user journey for the domain: discovering portraits via search, inspecting detailed metadata and citations, and obtaining the actual image. No obvious operational gaps exist for the stated purpose.
Search and fetch Wikidata entities, execute SPARQL queries, and resolve external identifiers.
Read-only OpenHeritage search for genealogy and cultural heritage records.
Search 14.5M Smithsonian Open Access objects, get CC0 images, find cross-collection connections.
Search biomedical papers, inspect publication records, and traverse citation or semantic graphs.