Ein MCP-Server, der eine Gruppe von Offline-ZIM-Dateien für lokale LLM-Agenten verfügbar macht. Geben Sie ein Verzeichnis mit ZIM-Dateien an, und der Server wird:
Den Inhalt inventarisieren (list_libraries) und aggregierte Funktionen (Allgemeinwissen, medizinisches Wissen, Karten/Routenplanung) basierend auf den geladenen Dateien bewerben.
Suche und Artikelabruf für jede ZIM-Datei bereitstellen (search, get_article, get_main_page).
Wenn er eine streetzim-ZIM-Datei erkennt, die mit --routing erstellt wurde, stellt er zusätzlich plan_driving_route, geocode und route_from_places bereit, sodass ein lokaler Agent fragen kann: "Gib mir eine Fahrtroute von A nach B" und Wegbeschreibungen, Distanz sowie eine geschätzte Zeit erhält.
Das Designprinzip ist opportunistische Funktionalität: Starten Sie mit einer Wikipedia-ZIM-Datei und Sie erhalten einen Wikipedia-Server. Fügen Sie mdwiki_en_all_*.zim hinzu, und er beantwortet auch medizinische Fragen. Fügen Sie eine streetzim-ZIM-Datei hinzu, und er kann auch Fahrtrouten für das von der ZIM-Datei abgedeckte Gebiet planen. Tools erscheinen nur, wenn die zugrunde liegenden Daten vorhanden sind, sodass die Tool-Liste des Agenten niemals falsche Versprechungen über die Fähigkeiten des Servers macht.
Erfordert Python 3.10+.
pip install mcpzim # once published
# or, from a checkout:
pip install -e .libzim ist ein natives Wheel; vorgefertigte Wheels existieren für macOS (x86_64/arm64), Linux (x86_64/aarch64, glibc und musl) und Windows x64. Auf anderen Plattformen baut pip aus dem Quellcode, und Sie benötigen eine C++-Toolchain.
Related MCP server: ZimAgent
Legen Sie Ihre ZIM-Dateien in ein Verzeichnis und führen Sie Folgendes aus:
export ZIM_DIR=~/zims
mcpzim # stdio transport (Claude Desktop / Code)
mcpzim ~/zims/wikipedia.zim ~/zims/streetzim_ma.zim # explicit paths
mcpzim --transport streamable-http --host 0.0.0.0 --port 8765 # LANFügen Sie dies zu ~/.config/claude-desktop/claude_desktop_config.json (oder dem Äquivalent für Ihren MCP-Client) hinzu:
{
"mcpServers": {
"mcpzim": {
"command": "mcpzim",
"env": { "ZIM_DIR": "/Users/me/zims" }
}
}
}Immer verfügbar:
Tool | Was es tut |
| Inventar: Listet jede ZIM-Datei mit Art, Titel, Sprache und den aggregierten Funktionen ( |
| Volltextsuche über jede ZIM-Datei (nutzt den Xapian-Index von libzim, falls vorhanden, ansonsten Titel-Präfix-Vorschläge). Akzeptiert einen optionalen |
| Ruft einen Eintrag über den Pfad ab; HTML wird von Navbox-/Infobox-/Skript-Ballast befreit, sodass das LLM sauberen Text sieht. |
| Hauptseite einer ZIM-Datei oder jeder geladenen ZIM-Datei. |
Nur vorhanden, wenn eine streetzim-ZIM-Datei mit Routing-Daten geladen ist:
Tool | Was es tut |
| A*-Suche über den streetzim-Routing-Graphen. Eingabe: zwei |
| Löst eine Orts-/Adresszeichenfolge mithilfe des präfix-gechunkten Suchindex von streetzim in Koordinaten auf. |
| Komfortfunktion: Geocodiert beide Endpunkte und plant dann eine Route. |
Kosten/Heuristik im Router entsprechen exakt dem JS-Viewer von streetzim:
edge_cost = distance_m / (speed_kmh / 3.6) und heuristic = haversine / (100/3.6), daher sind die Ergebnisse identisch mit denen, die der Browser-Viewer erzeugen würde.
Die Typenerkennung erfolgt zur Scan-Zeit und verwendet eine Kombination aus Dateinamen-Präfix, den Name / Tags / Creator / Publisher-Metadaten der ZIM-Datei sowie Signatureinträgen innerhalb des Archivs. Standardmäßig unterstützt:
Wikipedia — jede wikipedia_*.zim (Creator: Wikipedia, getaggt mit wikipedia).
mdwiki — mdwiki_*.zim von der WikiProjectMed Foundation (getaggt mit mdwiki / medical).
streetzim — erkannt durch das Vorhandensein von routing-data/graph.bin oder map-config.json innerhalb des Archivs.
generic — alles andere (eine *.zim wird trotzdem bereitgestellt; nur das Standard-Toolset ZimKind.GENERIC wird angewendet).
> list_libraries
{"zims": [
{"path": ".../wikipedia_en_all_nopic_2026-03.zim", "kind": "wikipedia", ...},
{"path": ".../mdwiki_en_all_2026-03.zim", "kind": "mdwiki", ...},
{"path": ".../streetzim_ma.zim", "kind": "streetzim", "has_routing": true, ...}
],
"by_kind": {"wikipedia": 1, "mdwiki": 1, "streetzim": 1},
"capabilities": ["encyclopedia", "general_knowledge", "geocode",
"get_article", "list_libraries", "maps", "medical",
"plan_route", "search"]}
> route_from_places {"origin": "Boston Common", "destination": "Fenway Park"}
{"origin_resolved": {"name": "Boston Common", "lat": 42.3554, "lon": -71.0655, ...},
"destination_resolved": {"name": "Fenway Park", "lat": 42.3467, "lon": -71.0972, ...},
"distance_km": 3.27, "duration_min": 9.4,
"roads": [
{"name": "Beacon Street", "distance_m": 412.3, "duration_s": 44.0},
...
],
"turn_by_turn": ["Beacon Street for 0.41 km (~0.7 min)", ...],
"polyline": [[42.3554, -71.0655], ...]}Die ehrliche Antwort: Das Ausführen von nativem Python + libzim auf iOS ist derzeit mühsam, da python-libzim keine iOS-Wheels hat und Sie die C++-libzim selbst cross-kompilieren müssten. Praktische Optionen, in der Reihenfolge des Aufwands:
LAN-Brücke (am einfachsten, funktioniert jetzt). Führen Sie mcpzim --transport streamable-http --host 0.0.0.0 auf einem Computer in Ihrem Netzwerk (oder einem Raspberry Pi) aus. Verbinden Sie Ihren mobilen Agenten damit. Die ZIM-Daten bleiben auf dem Heimserver; Ihr Telefon sieht nur einen funktionsreichen MCP-Endpunkt. Dies funktioniert heute ohne mobilen Code.
Android via Termux. pkg install python clang && pip install mcpzim in Termux baut libzim aus dem Quellcode. Führen Sie es auf dem Gerät aus, stellen Sie es über stdio (für einen lokalen Agentenprozess) oder streamable-http auf localhost für In-App-Clients bereit.
Swift/Kotlin-Port. Das SZRG v2-Routing-Format und die ZIM-Zugriffsschicht sind beide absichtlich unkompliziert. Ein Swift-MCP-Modul, das die C++-libzim über ihre Swift-Bindings aufruft (wie es Kiwix iOS bereits tut), könnte dieselbe Tool-Oberfläche wie dieser Python-Server bereitstellen. Das ist der beste Weg für eine iOS-Chat-App, die einen In-Process-MCP-Tool-Anbieter wünscht.
Kiwix-serve-Brücke. Die mobilen Kiwix-Apps betten bereits einen lokalen HTTP-Server ein; ein alternativer mcpzim-Modus, der an http://localhost:port/ weiterleitet, anstatt ZIM-Dateien direkt zu öffnen, würde überall dort funktionieren, wo Kiwix läuft. (Noch nicht implementiert — Pull Requests sind willkommen.)
pip install -e '.[dev]'
pytestTests erfordern keine echten ZIM-Dateien; die Routing-Tests erstellen einen kleinen SZRG v2-Graphen im Arbeitsspeicher unter Verwendung von mcpzim.routing.encode_graph_v2, und die Bibliothekstests prüfen den Klassifikator direkt.
MIT.
Fetch a single article by path, as plain text ready for reading.
Args:
path: the ZIM entry path (as returned in search results, e.g.
A/Aspirin).
zim: optional filename or path of the ZIM to read from. If
omitted, all loaded ZIMs are tried in scan order.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| zim | No |
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 mentions that the article is fetched 'as plain text ready for reading', which adds context about the output format. However, it lacks details on error handling (e.g., what happens if the path is invalid), performance (e.g., speed or size limits), or side effects, leaving gaps in behavioral transparency.
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 the core purpose in the first sentence, followed by a structured 'Args:' section that efficiently explains parameters without redundancy. Every sentence adds value, and there is no wasted text, making it highly concise and well-structured.
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 tool's moderate complexity (2 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and parameters well but lacks information on return values (since no output schema exists), error conditions, or dependencies on sibling tools. This leaves some gaps for an AI agent to fully understand the tool's behavior.
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 schema description coverage is 0%, so the description must compensate. It provides clear semantics for both parameters: 'path' is explained as 'the ZIM entry path (as returned in search results, e.g., ``A/Aspirin``)', and 'zim' is described as 'optional filename or path of the ZIM to read from' with behavior when omitted. This adds meaningful context beyond the bare schema, though it could include examples or constraints for 'zim'.
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 specific action ('Fetch a single article by path') and resource ('article'), distinguishing it from sibling tools like 'list_libraries' (which lists libraries) and 'search' (which searches across content). It also specifies the output format ('as plain text ready for reading'), which further clarifies its purpose.
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 implies usage by mentioning 'as returned in search results' for the path parameter, suggesting it should be used after a search. However, it does not explicitly state when to use this tool versus alternatives like 'get_main_page' or provide exclusions, leaving some ambiguity about the ideal context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the main/home page of a ZIM. If no zim name is given, returns the main page of every loaded ZIM.
| Name | Required | Description | Default |
|---|---|---|---|
| zim | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the conditional behavior based on the 'zim' parameter, which is useful. However, it lacks details on permissions, rate limits, error handling, or what 'loaded ZIM' means in practice. For a tool with no annotations, this leaves significant gaps in understanding its operational traits.
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 extremely concise—just two sentences—with zero wasted words. It front-loads the core purpose and efficiently explains the parameter's effect. Every sentence earns its place by adding critical information, making it easy to parse and understand quickly.
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 tool's low complexity (1 optional parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic purpose and parameter semantics adequately. However, without annotations or output schema, it should ideally mention more about behavioral aspects like return format or error cases. It's minimally viable but could be more comprehensive for full contextual understanding.
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 description adds meaningful context for the single parameter 'zim': it explains that if no zim name is given, it returns the main page of every loaded ZIM. This clarifies the parameter's optional nature and its impact on behavior. Since schema description coverage is 0%, the description compensates well by providing semantic understanding beyond the bare schema, though it could specify what a 'zim name' format entails.
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 ('Fetch') and resource ('main/home page of a ZIM'), making the purpose understandable. It distinguishes from siblings like 'get_article' by focusing on the main page rather than specific articles, though it doesn't explicitly contrast them. The purpose is specific but could be more precise about what a 'main page' entails.
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 implies when to use it by stating the conditional behavior: use with a zim name to fetch a specific ZIM's main page, or without to get all loaded ZIMs' main pages. However, it doesn't provide explicit guidance on when to choose this tool over alternatives like 'list_libraries' or 'search', nor does it mention any prerequisites or exclusions. The usage context is implied but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inventory the ZIM archives this server can read.
Returns a list of archives with their kind (wikipedia / mdwiki /
streetzim / generic), metadata, and the aggregate capabilities exposed
(e.g. plan_route is only present when a streetzim ZIM is loaded).
Call this first so you know what sources and tools are available.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 the tool's behavior by specifying the return format ('list of archives with their kind, metadata, and aggregate capabilities') and implying it's a read-only inventory operation (no destructive actions mentioned). However, it lacks details on potential errors, rate limits, or authentication requirements, which are minor gaps.
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 the core purpose in the first sentence, followed by details on returns and usage guidance. Every sentence earns its place: the first explains what it does, the second details the output, and the third provides critical context on when to use it. There is no wasted text, and it's structured for clarity.
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 tool's complexity (simple inventory with 0 parameters) and lack of annotations/output schema, the description is largely complete. It covers purpose, output details, and usage context. However, it doesn't specify the exact structure of the returned list or error handling, which are minor omissions for a tool of this simplicity.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately focuses on output semantics, explaining what information is returned (e.g., archive kinds, metadata, capabilities like 'plan_route'). This adds value beyond the empty input schema, justifying a score above the baseline of 3.
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 specific action ('Inventory') and resource ('ZIM archives this server can read'), distinguishing it from sibling tools like get_article, get_main_page, and search by focusing on system inventory rather than content retrieval. It explicitly mentions what is returned ('list of archives with their kind, metadata, and aggregate capabilities'), making the purpose unambiguous.
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: 'Call this first so you know what sources and tools are available.' This indicates it should be used as an initial step to discover available resources before invoking other tools, clearly differentiating it from siblings that perform content operations.
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 all loaded ZIMs.
Args:
query: search terms.
limit: max results per ZIM (default 10).
kind: optional filter, one of wikipedia, mdwiki,
streetzim, generic.
Each hit includes the source ZIM, path, title and a short snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| limit | No | ||
| kind | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the scope ('across all loaded ZIMs') and describes the return format ('Each hit includes the source ZIM, path, title and a short snippet'), but doesn't address important behavioral aspects like whether this is a read-only operation, performance characteristics, error conditions, or pagination behavior. For a search tool with zero annotation coverage, this leaves significant gaps.
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 perfectly structured and concise. It begins with the core purpose statement, then provides a well-organized parameter section with clear explanations for each parameter. Every sentence earns its place, and the information is front-loaded with the most important details first.
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 tool's moderate complexity (search across multiple ZIMs), no annotations, no output schema, and 3 parameters, the description provides adequate but incomplete coverage. It explains parameters well and describes the return format, but lacks information about authentication requirements, rate limits, error handling, or the relationship between 'limit per ZIM' and total results across multiple ZIMs.
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 must compensate for the lack of parameter documentation in the schema. The description successfully adds meaning for all three parameters: explaining 'query' as 'search terms', 'limit' as 'max results per ZIM' with default value, and 'kind' as an 'optional filter' with enumerated values. This provides clear semantic understanding 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 performs 'Full-text search across all loaded ZIMs' which is a specific verb+resource combination. It distinguishes itself from sibling tools like 'get_article' (retrieves specific content), 'get_main_page' (gets homepage), and 'list_libraries' (lists available libraries). However, it doesn't explicitly contrast with these siblings in the description text itself.
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 implies usage context through the phrase 'across all loaded ZIMs' and the parameter documentation, but doesn't explicitly state when to use this tool versus alternatives. No guidance is provided about when not to use it or what specific scenarios warrant choosing 'search' over sibling tools like 'get_article' for direct content retrieval.
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.0get_articleget_main_pagelist_librariessearchScored across 4 tools
Each tool has a clearly distinct purpose with no overlap: get_article fetches a specific article, get_main_page retrieves the main page, list_libraries inventories available archives, and search performs full-text queries. The descriptions clearly differentiate their functions, eliminating any ambiguity.
All tool names follow a consistent verb_noun pattern (get_article, get_main_page, list_libraries, search), with 'search' being a concise exception that still fits the verb-first style. The naming is uniform and predictable across the set.
With 4 tools, this server is well-scoped for its purpose of accessing ZIM archives. Each tool earns its place by covering essential operations: inventorying sources, retrieving content (specific articles and main pages), and searching. The count is neither too sparse nor bloated.
The tool set provides complete coverage for the domain of reading and searching ZIM archives. It includes discovery (list_libraries), content retrieval (get_article, get_main_page), and search capabilities, with no obvious gaps. Agents can navigate from listing to fetching or searching seamlessly.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Hosted MCP server for live public-data APIs and Skills for AI agents.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
