Provides full-text search of Projekt Runeberg content using DuckDuckGo as the default privacy-respecting search backend, requiring no API keys.
Supports Google Custom Search JSON API for site-restricted searches of runeberg.org, enabling higher-volume or specialized search setups.
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., "@runeberg-mcp what is the table of contents for Strindberg's Dödsdansen?"
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 (MCP) server and CLI tool for searching and reading digitized classic Nordic literature, historical encyclopedias, biographies, and source documents from Projekt Runeberg.
Project Runeberg has been publishing free electronic editions of classic Nordic literature out of copyright since 1992. It includes vast cultural treasures such as Nordisk familjebok, Svenskt biografiskt handlexikon, Salmonsens konversationsleksikon, parish histories, memoirs, drama, and poetry.
🔎 Full-Text Search (runeberg_search): Search the actual text of millions of scanned book pages across Projekt Runeberg.
📄 Clean Page Reading (runeberg_read_page): Extract and format the transcribed/OCR text for any page, stripped of web markup and navigation. Includes links to original facsimile scans.
📚 Work & Chapter Inspector (runeberg_get_work_info): Retrieve metadata, authors, publication years, and tables of contents/chapter links for any digitized volume.
⚡ Zero-Config by Default: Works out-of-the-box using privacy-respecting search backends (DuckDuckGo/multi-engine) without requiring any API keys.
🚀 Optional Google Custom Search API: Supports official Google Custom Search JSON API for high-volume or specialized setups.
🛠️ Dual-mode CLI & MCP: Use directly in your terminal as a CLI or seamlessly integrate with LLM agents (Claude Desktop, Cursor, Antigravity, etc.).
Related MCP server: DHLAB MCP Server
Managed with modern Python packaging via uv:
git clone https://github.com/tobbaz/runeberg-mcp.git
cd runeberg-mcp
uv syncTo connect this MCP server to your AI assistant, add it to your client's configuration file.
claude_desktop_config.json)On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"runeberg": {
"command": "uv",
"args": [
"--directory",
"/path/to/runeberg-mcp",
"run",
"runeberg-mcp",
"serve"
]
}
}
}Configure as a stdio MCP server with:
Command: uv
Args: ["--directory", "/path/to/runeberg-mcp", "run", "runeberg-mcp", "serve"]
By default, searches against site:runeberg.org run via multi-engine fallback (ddgs), requiring no API keys or signups.
If you prefer to query Google's official Custom Search API:
Create an API key in the Google Cloud Console.
Create a Programmable Search Engine configured to search runeberg.org/*.
Set the environment variables in your client configuration:
{
"mcpServers": {
"runeberg": {
"command": "uv",
"args": ["--directory", "/path/to/runeberg-mcp", "run", "runeberg-mcp", "serve"],
"env": {
"GOOGLE_API_KEY": "your-google-api-key",
"GOOGLE_CSE_ID": "your-custom-search-engine-id"
}
}
}
}You can test and use the tool directly in your terminal:
uv run runeberg-mcp search "Dödsdansen"
uv run runeberg-mcp search "Abraham Brodersson"# By work slug and page number:
uv run runeberg-mcp read dasakungen 5
# Or by full URL:
uv run runeberg-mcp read https://runeberg.org/strindbg/dodsdans/0057.htmluv run runeberg-mcp info dasakungen
uv run runeberg-mcp info sbhRun the test suite to verify search, retrieval, and text parsing:
uv run python test_server.pyDistributed under the MIT License. Digital works hosted on Projekt Runeberg are public domain cultural heritage.
Get metadata, publication details, and table of contents/chapter list for a work in Project Runeberg.
Args:
work_slug: The work identifier (e.g. 'dasakungen', 'sbh', 'nfda', 'salmonsen').
| Name | Required | Description | Default |
|---|---|---|---|
| work_slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It clearly communicates a read-only 'get' operation and what the result will contain. It does not disclose potential error behavior or rate limits, but for a simple retrieval tool this is not a major gap.
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 two sentences plus a parameter block with no filler. The purpose is front-loaded and the parameter explanation is immediately actionable.
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?
With only one required parameter and an output schema present, the description is nearly complete. The only missing context is a brief nod to the sibling tools or how to obtain a valid work_slug, but that is a minor omission for this low-complexity tool.
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 coverage is 0%, but the description fully compensates by explaining work_slug as 'The work identifier' and giving four concrete examples. This tells the agent exactly what value to supply and what form it takes.
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 a specific verb ('Get'), a concrete resource ('a work in Project Runeberg'), and the exact information returned (metadata, publication details, table of contents/chapter list). This makes it easy to distinguish from the sibling tools runeberg_search and runeberg_read_page.
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 use case is implied: after you already have a work_slug, this tool fetches overview information. However, the description does not explicitly contrast this with searching for works or reading pages, so the agent must infer when to select this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the cleaned, transcribed/OCR text of a specific book page from Project Runeberg.
Args:
url_or_slug: Full page URL (e.g. 'https://runeberg.org/pvmhall/0105.html') or work slug (e.g. 'pvmhall').
page: Optional page number if slug was provided (e.g. '0105' or 105).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| url_or_slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses that this is a read operation returning cleaned/OCR text and that the page parameter only applies when a slug is used. However, it does not state what happens when a slug is provided without a page, how invalid inputs are handled, or whether any normalization occurs.
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 compact and front-loaded: the purpose appears in the first sentence, followed by a clean Args section. Every sentence adds necessary information and there is no filler.
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?
With an output schema present, return-value details do not need to be in the description. The two parameters are thoroughly documented and the read behavior is clear. The main gaps are the lack of explicit sibling differentiation and the unspecified default behavior when page is omitted, but overall this is nearly complete for a simple read tool.
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 is the only documentation for the parameters. It fully explains url_or_slug with a concrete URL and slug example, and page with both string and numeric examples, while also clarifying the conditional relationship between the two parameters.
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 action ('Read') and the resource ('cleaned, transcribed/OCR text of a specific book page from Project Runeberg'). This distinguishes it from the sibling tools runeberg_search and runeberg_get_work_info, which serve clearly different purposes.
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 the use case clear: retrieve page text when you have a full page URL or a work slug plus optional page number. It does not explicitly mention alternatives or exclusions, but the context is strong enough for an agent to infer when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across digitized books, encyclopedias, and literature in Project Runeberg (runeberg.org).
Args:
query: Search keywords or phrases (e.g. "Abraham Brodersson", "Dödsdansen", or "Falun gruva").
max_results: Maximum number of search results to return (default: 10).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. It clearly states this is a full-text search operation, which implies a read-only, non-destructive action. However, it does not disclose details such as result behavior, pagination, authentication needs, or any search limitations.
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 compact and front-loaded: the first sentence states the core purpose, followed by a clean Args section. There is no redundant or filler content.
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 tool is simple, has only two parameters, and an output schema exists, so the return format does not need to be explained. The description covers purpose and all parameters well, though it could be slightly stronger by noting when to prefer this over sibling tools.
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 compensate. It fully does: query is explained with concrete examples ('Abraham Brodersson', 'Dödsdansen') and max_results is described with its default value, adding practical meaning 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 states a specific verb and resource: 'Full-text search across digitized books, encyclopedias, and literature in Project Runeberg.' It clearly distinguishes this tool from siblings like runeberg_read_page and runeberg_get_work_info, which are about reading pages or fetching work metadata rather than searching.
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 about when to use this tool versus the sibling tools. The description explains what the search does, but it does not mention exclusions, preferred use cases, or when a different tool would be more appropriate.
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.
v0.1.0runeberg_get_work_inforuneberg_read_pageruneberg_searchScored across 3 tools
Each tool serves a distinct purpose: search for discovery, read_page for content access, and get_work_info for metadata. No overlap in functionality or ambiguous boundaries.
All tool names follow the same pattern: 'runeberg_' prefix with verb_noun structure (search, read_page, get_work_info). Consistent use of snake_case and clear verbs.
With only 3 tools, the set is minimal but appropriate for a focused read-only library access server. It covers search, retrieval, and metadata without excess.
The tools cover the core lifecycle: discover (search), access (read_page), and understand context (get_work_info). Minor gaps exist, such as lack of a browse/list tool, but search effectively covers discovery.
Search books and authors, fetch editions, browse subjects, and resolve cover images.
Search Wikipedia, read summaries and full text, target sections, find nearby pages, list languages.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Academic literature search, retrieval, and private library management on top of OpenAlex.
