The Riksarkivet MCP Server enables searching and browsing millions of transcribed historical documents from the Swedish National Archives through AI assistants and command-line tools.
Core Capabilities:
Full-text search with advanced query syntax including wildcards (*, ?), fuzzy matching (~), proximity searches, boolean operators (AND/OR/NOT), and term boosting. Results support pagination, configurable hits per document (default: 3), and toggleable context display for balancing coverage with detail.
Document browsing by reference code with support for single pages, ranges (e.g., "1-10"), or comma-separated lists. View full transcriptions with optional search term highlighting and configurable page limits (default: 20).
Document structure and metadata retrieval including reference codes, PIDs, institution information, dates, and IIIF manifest data without fetching full content.
Archive guide navigation with access to a complete guide index and specific sections covering topics like courts (Domstolar) and prisons (Fängelse).
Integration features including ALTO XML transcriptions for structured data, IIIF high-resolution images with zoom/crop capabilities, interactive web viewers (Bildvisning), and integration with Riksarkivet APIs (Search API, IIIF Collections, OAI-PMH, semantic search).
Deployment options as an MCP server for AI assistants like Claude and ChatGPT via HTTP transport, command-line interface for local usage, and containerized deployment with development tools including MCP Inspector testing and Dagger-based CI/CD.
Typical workflow: Search using keywords → Paginate through results → Browse specific pages with highlighted terms → Access original images and metadata for citations.
Click on "Install 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., "@Riksarkivet MCP Server search for documents about witchcraft trials in Stockholm"
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.
A Model Context Protocol server and CLI for searching and browsing transcribed historical documents from the Swedish National Archives (Riksarkivet). Provides full-text search across millions of AI-transcribed pages, complete page transcriptions, handwritten text recognition, interactive document viewing, and archival research guides — all as MCP tools that any LLM client can use.
Streamable HTTP — works with ChatGPT, Claude, and any MCP-compatible client:
https://riksarkivet-ra-mcp.hf.space/mcpClaude Code:
claude mcp add --transport http ra-mcp https://riksarkivet-ra-mcp.hf.space/mcpIDE (mcp.json):
{
"mcpServers": {
"ra-mcp": {
"type": "streamable-http",
"url": "https://riksarkivet-ra-mcp.hf.space/mcp"
}
}
}Claude.ai (web & desktop) — no install: it's a remote server, so add it as a custom connector by URL. Settings → Connectors → Add custom connector → paste https://riksarkivet-ra-mcp.hf.space/mcp → Add. The ra-mcp tools then appear in new chats. (Requires a plan with custom connectors: Pro, Max, Team, or Enterprise.)
ChatGPT (Pro/Business/Enterprise): Settings → Connectors (or enable Developer mode) → add a connector pointing at the same URL. See OpenAI's connector docs for the current flow.
The interactive document / PDF viewers are MCP App UIs — they render inline only in clients that support MCP UI resources (e.g. Claude). Other clients still get all the text/search/browse tools; they just won't embed the viewer.
The
.claude/skills and theplugins/ra-mcp-toolsplugin are Claude Code add-ons (/install-plugin AI-Riksarkivet/ra-mcp plugins/ra-mcp-tools). They aren't used by claude.ai or ChatGPT, which call the MCP tools directly.
Related MCP server: KB MCP Server
The ra command imports the search, browse, and TUI sub-apps unconditionally, so install the cli and tui extras to get a working CLI:
uv pip install "ra-mcp[cli,tui]"# Search transcribed documents
ra search "trolldom"
ra search "Stockholm troll*"
# Browse specific pages
ra browse "SE/RA/310187/1" --pages "7,8,52" --search-term "trolldom"
# Interactive terminal browser
ra tui "trolldom"For architecture, development setup, deployment, tool reference, CLI reference, and more:
ai-riksarkivet.github.io/ra-mcp
Browse specific pages of a document by reference code and view full transcriptions.
This tool retrieves complete page transcriptions from historical documents in Swedish.
Each result includes the full transcribed text as it appears in the original document,
plus direct links to view the original page images in Riksarkivet's image viewer (bildvisaren).
Prefer showing the whole transcription and link in responses of individual pages.
Download some of the nearby pages too on selected pages if context seem to be missing from the trancript
to get a better picture
Original text:
transcript
Translation
Modern translation in language of user
Links
Key features:
- Returns full page transcriptions in (original language)
- Provides links to bildvisaren (Riksarkivet's image viewer) for viewing original documents
- Supports single pages, page ranges, or multiple specific pages
- Direct links to ALTO XML for detailed text layout information
Parameters:
- reference_code: Document reference code from search results (e.g., "SE/RA/420422/01")
- pages: Page specification - single ("5"), range ("1-10"), or comma-separated ("5,7,9")
- highlight_term: Optional keyword to highlight in the transcription
- max_pages: Maximum number of pages to retrieve (default: 20)
Examples:
- browse_document("SE/RA/420422/01", "5") - View full transcription of page 5
- browse_document("SE/RA/420422/01", "1-10") - View pages 1 through 10
- browse_document("SE/RA/420422/01", "5,7,9", highlight_term="Stockholm") - View specific pages with highlighting
Note: Transcriptions are as they appear in the historical documents.
Use this tool when you need complete page content rather than just search snippets.
| Name | Required | Description | Default |
|---|---|---|---|
| reference_code | Yes | ||
| pages | Yes | ||
| highlight_term | No | ||
| max_pages | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it retrieves transcriptions in Swedish, includes links to original images and ALTO XML, supports various page specifications, and notes transcriptions are as they appear historically. It lacks details on rate limits or error handling, but covers core operational traits well.
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 front-loaded with core purpose but includes verbose sections like 'Key features' and 'Examples' that repeat information. Sentences like 'Download some of the nearby pages too...' are ambiguous and could be trimmed. It's informative but not optimally concise, with some redundancy.
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?
Given 4 parameters with 0% schema coverage, no annotations, but an output schema exists, the description does well. It covers purpose, usage, parameters, and examples thoroughly. The output schema likely handles return values, so the description appropriately focuses on input and behavior. Minor gaps in error handling or limits keep it from a perfect score.
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?
Schema description coverage is 0%, so the description must fully compensate. It provides detailed semantics for all parameters: explains 'reference_code' format with examples, describes 'pages' syntax for single/range/multiple, clarifies 'highlight_term' as optional keyword highlighting, and specifies 'max_pages' default and purpose. This adds substantial value beyond the bare schema.
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 clearly states the tool's purpose: 'Browse specific pages of a document by reference code and view full transcriptions.' It specifies the verb ('browse'), resource ('document pages'), and distinguishes from the sibling tool 'search_transcribed' by emphasizing complete page content rather than search snippets.
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 provides explicit guidance on when to use this tool: 'Use this tool when you need complete page content rather than just search snippets.' This directly contrasts with the sibling tool 'search_transcribed' (implied to provide snippets), offering clear alternatives and context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for keywords in transcribed historical documents from the Swedish National Archives (Riksarkivet).
This tool searches through historical documents and returns matching pages with their transcriptions.
Supports advanced Solr query syntax including wildcards, fuzzy search, Boolean operators, and proximity searches.
Key features:
- Returns document metadata, page numbers, and text snippets containing the keyword
- Provides direct links to page images and ALTO XML transcriptions
- Supports pagination via offset parameter for comprehensive discovery
- Advanced search syntax for precise queries
Search syntax examples:
- Basic: "Stockholm" - exact term search
- Wildcards: "Stock*", "St?ckholm", "*holm" - match patterns
- Fuzzy: "Stockholm~" or "Stockholm~1" - find similar words (typos, variants)
- Proximity: '"Stockholm trolldom"~10' - words within 10 words of each other
- Boolean: "(Stockholm AND trolldom)", "(Stockholm OR Göteborg)", "(Stockholm NOT trolldom)"
- Boosting: "Stockholm^4 trol*" - increase relevance of specific terms
- Complex: "((troll* OR häx*) AND (Stockholm OR Göteborg))" - combine operators
NOTE: make sure to use grouping () for any boolean search also "" is important to group multiple words
E.g do '((skatt* OR guld* OR silver*) AND (stöld* OR stul*))' instead of '(skatt* OR guld* OR silver*) AND (stöld* OR stul*)', i.e prefer grouping as that will retrun results, non-grouping will return 0 results
also prefer to use fuzzy search i.e. something like ((stöld~2 OR tjufnad~2) AND (silver* OR guld*)) AND (döm* OR straff*) as many trancriptions are OCR/HTR AI based with common errors. Also account for old swedish i.e (((präst* OR prest*) OR (kyrko* OR kyrck*)) AND ((silver* OR silfv*) OR (guld* OR gull*)))
Proximity guide:
Use quotes around the search terms
"term1 term2"~N ✅
term1 term2~N ❌
Only 2 terms work reliably
"kyrka stöld"~10 ✅
"kyrka silver stöld"~10 ❌
The number indicates maximum word distance
~3 = within 3 words
~10 = within 10 words
~50 = within 50 words
📊 Working Examples by Category:
Crime & Punishment:
"tredje stöld"~5 # Third-time theft
"dömd hänga"~10 # Sentenced to hang
"inbrott natt*"~5 # Burglary at night
"kyrka stöld"~10 # Church theft
Values & Items:
"hundra daler"~3 # Hundred dalers
"stor* stöld*"~5 # Major theft
"guld* ring*"~10 # Gold ring
"silver* kalk*"~10 # Silver chalice
Complex Combinations:
("kyrka stöld"~10 OR "kyrka tjuv*"~10) AND 17*
# Church thefts or church thieves in 1700s
("inbrott natt*"~5) AND (guld* OR silver*)
# Night burglaries involving gold or silver
("första resan" AND stöld*) OR ("tredje stöld"~5)
# First-time theft OR third theft (within proximity)
🔧 Troubleshooting Tips:
If proximity search returns no results:
Check your quotes - Must wrap both terms
Reduce to 2 terms - Drop extra words
Try exact terms first - Before wildcards
Increase distance - Try ~10 instead of ~3
Simplify wildcards - Use on one term only
💡 Advanced Strategy:
Layer your searches from simple to complex:
Step 1: "kyrka stöld"~10
Step 2: ("kyrka stöld"~10 OR "kyrka tjuv*"~10)
Step 3: (("kyrka stöld"~10 OR "kyrka tjuv*"~10) AND 17*)
Step 4: (("kyrka stöld"~10 OR "kyrka tjuv*"~10) AND 17*) AND (guld* OR silver*)
Most Reliable Proximity Patterns:
Exact + Exact: "hundra daler"~3
Exact + Wildcard: "inbrott natt*"~5
Wildcard + Wildcard (sometimes): "stor* stöld*"~5
The key is that proximity operators in this system work best with exactly 2 terms in quotes, and you can then combine multiple proximity searches using Boolean operators outside the quotes!
Parameters:
- keyword: Search term or Solr query (required)
- offset: Starting position for pagination - use 0, then 50, 100, etc. (required)
- max_results: Maximum documents to return per query (default: 10)
- max_hits_per_document: Maximum matching pages per document (default: 3)
- max_response_tokens: Maximum tokens in response (default: 15000)
Best practices:
- Start with offset=0 and increase by 50 to discover all matches
- Search related terms and variants for comprehensive coverage
- Use wildcards (*) for word variations: "troll*" finds "trolldom", "trolleri", "trollkona"
- Use fuzzy search (~) for historical spelling variants
- Use browse_document tool to view full page transcriptions of interesting results
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | ||
| offset | Yes | ||
| max_results | No | ||
| max_hits_per_document | No | ||
| max_response_tokens | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It explains the search capabilities (Solr query syntax), return format (document metadata, page numbers, text snippets), pagination behavior, and provides extensive examples and troubleshooting guidance for effective use.
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?
While the description is comprehensive and well-structured with clear sections, it is extremely lengthy with extensive examples, troubleshooting tips, and advanced strategies that could be condensed. The core information is front-loaded, but the overall length exceeds what's typically needed for effective tool selection.
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?
Given the complexity of the search functionality, 0% schema description coverage, no annotations, and the presence of an output schema, the description provides complete contextual information. It covers purpose, usage, parameters, behavioral characteristics, examples, troubleshooting, and integration with sibling tools, making it fully self-contained for an AI agent.
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?
With 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all parameters. It explains 'keyword' supports advanced Solr syntax with extensive examples, 'offset' for pagination with specific increments, and provides default values and usage guidance for all other parameters in the 'Best practices' section.
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 clearly states the tool searches for keywords in transcribed historical documents from the Swedish National Archives, specifying it returns matching pages with transcriptions. It distinguishes from the sibling 'browse_document' tool by focusing on search functionality rather than viewing full transcriptions.
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 provides explicit guidance on when to use this tool vs alternatives, mentioning to use 'browse_document tool to view full page transcriptions of interesting results.' It also includes troubleshooting tips and advanced strategy sections that guide users on effective usage patterns.
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. Dates show when Glama detected each change.
v1.0.0get_document_structuresearch_transcribed5 fields changedInput schema / properties / context_paddingRemoved value: -{
- "default": 0,
- "title": "Context Padding",
- "type": "integer"
-}Input schema / properties / max_pages_with_contextRemoved value: -{
- "default": 0,
- "title": "Max Pages With Context",
- "type": "integer"
-}Input schema / properties / max_results / defaultPrevious value: -10New value: +50Input schema / properties / show_contextRemoved value: -{
- "default": false,
- "title": "Show Context",
- "type": "boolean"
-}Input schema / properties / truncate_page_textRemoved value: -{
- "default": 800,
- "title": "Truncate Page Text",
- "type": "integer"
-}browse_documentget_document_structuresearch_transcribedThe two tools have clearly distinct purposes: 'search_transcribed' is for discovering documents via keyword searches, while 'browse_document' is for retrieving full transcriptions of specific pages. There is no overlap or ambiguity between them; each serves a different stage in the document exploration workflow.
Both tools follow a consistent verb_noun naming pattern ('search_transcribed' and 'browse_document'), using snake_case throughout. The verbs 'search' and 'browse' accurately reflect their distinct functions, and the pattern is uniform across the tool set.
With only two tools, the server feels under-scoped for its domain of historical document exploration. While the tools cover search and viewing, there are likely missing operations such as filtering by metadata, listing document collections, or handling user sessions. A typical server in this domain would benefit from 5-10 tools for a more complete surface.
The server provides core search and browse functionality, but there are notable gaps. It lacks tools for document metadata retrieval, collection browsing, or advanced filtering beyond keyword search. Agents can work around this by using the existing tools iteratively, but the surface is incomplete for comprehensive historical research workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Search, read, and automate TextMine documents, records, workflows, integrations, and agent tasks.
Read-only OpenHeritage search for genealogy and cultural heritage records.
Web search and page-reading for AI agents. One-click OAuth connect, or a Caesar API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AI-Riksarkivet/ra-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
