ローカルのLLMエージェントがオフラインのZIMファイル群を利用できるようにするMCPサーバーです。ZIMファイルを格納したディレクトリを指定すると、サーバーは以下の処理を行います。
何があるかをインベントリ化し（list_libraries）、読み込まれた内容に基づいて集約された機能（一般知識、医学知識、地図/経路案内）をアドバタイズします。
すべてのZIMにわたる検索および記事取得機能（search、get_article、get_main_page）を公開します。
--routingオプション付きでビルドされたstreetzim ZIMを検出すると、plan_driving_route、geocode、route_from_placesを追加で公開します。これにより、ローカルエージェントが「AからBまでのドライブ経路を教えて」と尋ねると、道路ごとの指示、距離、推定時間を取得できるようになります。
設計原則は**日和見的な機能（opportunistic capability）**です。WikipediaのZIMを1つから始めればWikipediaサーバーとして機能します。mdwiki_en_all_*.zimを追加すれば医学的な質問にも回答できるようになります。streetzimのZIMを追加すれば、そのZIMがカバーする地域のドライブ経路も計画できるようになります。ツールは基盤となるデータが存在する場合にのみ表示されるため、エージェントのツールリストがサーバーの能力について嘘をつくことはありません。
Python 3.10以上が必要です。
pip install mcpzim # once published
# or, from a checkout:
pip install -e .libzimはネイティブホイールです。macOS（x86_64/arm64）、Linux（x86_64/aarch64、glibcおよびmusl）、Windows x64向けのビルド済みホイールが存在します。その他のプラットフォームではpipがソースからビルドするため、C++ツールチェーンが必要になります。
Related MCP server: ZimAgent
ZIMファイルを1つのディレクトリに配置し、以下を実行します。
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 # LAN~/.config/claude-desktop/claude_desktop_config.json（またはお使いのMCPクライアントの同等ファイル）に追加します。
{
"mcpServers": {
"mcpzim": {
"command": "mcpzim",
"env": { "ZIM_DIR": "/Users/me/zims" }
}
}
}常に利用可能:
ツール | 機能 |
| インベントリ：種類、タイトル、言語、および集約された機能（ |
| すべてのZIMにわたる全文検索（存在する場合はlibzimのXapianインデックスを使用し、なければタイトルプレフィックスの提案にフォールバックします）。オプションの |
| パスでエントリを取得します。HTMLからnavbox / infobox / スクリプトの不要な部分が削除されるため、LLMはクリーンなテキストを確認できます。 |
| 1つのZIM、または読み込まれたすべてのZIMのメインページを取得します。 |
経路データを含むstreetzim ZIMが読み込まれている場合にのみ表示:
ツール | 機能 |
| streetzimルーティンググラフ上でのA*探索。入力：2つの |
| streetzimのプレフィックスチャンク検索インデックスを使用して、場所/住所文字列を座標に解決します。 |
| 利便性：両方の終点をジオコードしてから経路を計画します。 |
ルーター内のコスト/ヒューリスティックはstreetzimのJSビューアと完全に一致します：
edge_cost = distance_m / (speed_kmh / 3.6) および heuristic = haversine / (100/3.6)。そのため、結果はブラウザ内のビューアが生成するものと同一になります。
型検出はスキャン時に実行され、ファイル名のプレフィックス、ZIMのName / Tags / Creator / Publisherメタデータ、およびアーカイブ内の署名エントリを組み合わせて使用します。標準でサポートされるもの：
Wikipedia — wikipedia_*.zim（Creator: Wikipedia、タグwikipedia）。
mdwiki — WikiProjectMed Foundationによるmdwiki_*.zim（タグmdwiki / medical）。
streetzim — アーカイブ内のrouting-data/graph.binまたはmap-config.jsonの存在によって検出されます。
generic — その他すべて（*.zimは引き続き提供されますが、ZimKind.GENERICのデフォルトツールセットのみが適用されます）。
> 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], ...]}正直な回答：python-libzimにはiOS用のホイールがないため、現在iOS上でネイティブPython + libzimを実行するのは困難です。C++のlibzimを自分でクロスコンパイルする必要があります。努力の少ない順に実用的な選択肢を挙げます：
LANブリッジ（最も簡単、現在動作可能）。 ネットワーク上のマシン（またはRaspberry Pi）で mcpzim --transport streamable-http --host 0.0.0.0 を実行します。モバイルエージェントをそこに向けてください。ZIMデータはホームサーバー上に留まり、スマートフォンは機能豊富なMCPエンドポイントを参照するだけです。これはモバイルコードなしで現在動作します。
Termux経由のAndroid。 Termuxで pkg install python clang && pip install mcpzim を実行すると、libzimがソースからビルドされます。デバイス上で実行し、stdio（ローカルエージェントプロセス用）またはlocalhost上のstreamable-httpを介してアプリ内クライアントに公開します。
Swift/Kotlinへの移植。 SZRG v2ルーティング形式とZIMアクセス層はどちらも意図的に単純化されています。（Kiwix iOSが既に行っているように）Swiftバインディングを通じてC++のlibzimを呼び出すSwift MCPモジュールを作成すれば、このPythonサーバーと同じツールインターフェースを公開できます。これが、プロセス内MCPツールプロバイダーを求めるiOSチャットアプリにとって最善の道です。
Kiwix-serveブリッジ。 Kiwixモバイルアプリは既にローカルHTTPサーバーを埋め込んでいます。ZIMを直接開く代わりに http://localhost:port/ にプロキシする代替のmcpzimモードがあれば、Kiwixが動作する場所ならどこでも機能します。（未実装 — プルリクエスト歓迎。）
pip install -e '.[dev]'
pytestテストに実際のZIMファイルは必要ありません。ルーティングテストは mcpzim.routing.encode_graph_v2 を使用してメモリ内で小さなSZRG v2グラフを構築し、ライブラリテストは分類器を直接実行します。
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.
