Skip to main content
Glama
cameronrye

OpenZIM MCP Server

by cameronrye
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

zim_get

Read-only

Fetch articles, summaries, tables of contents, or binary files from offline ZIM archives. Retrieve single entries, batches, or the main page from a knowledge base.

Instructions

Fetch entries from a ZIM archive — single, batch, binary, or main page.

EXTRACT the right path-shape before calling — the parameters form four mutually-exclusive branches:

  • Single entry, body view (default): pass entry_path + optional view. Returns the article body for view="full", a short summary for view="summary", a TOC tree for view="toc", a flat section list for view="structure".

  • Single entry, binary: pass entry_path + binary=True. Returns raw bytes (image, video, PDF, etc.). view is locked to "full" in this branch.

  • Batch: pass entry_paths (list of strings). Returns each entry's clean body, first page only; non-full view / content_offset return invalid_path_combination.

  • Main page: pass main_page=True (no entry_path). Returns the archive's main page. view, entry_path, entry_paths, binary are all forbidden in this branch.

ALIASES: callers may say "get article", "fetch", "show me ", "summary of ", "structure of ", "main page". Route through THIS tool with the matching branch.

PARAMETERS: zim_file_path REQUIRED. The archive containing the entry. entry_path Single-entry path (string). Mutually exclusive with entry_paths and main_page. entry_paths Batch-mode path list. Mutually exclusive with entry_path, binary, main_page. view Body slice when not binary/main_page: "full" (default, full markdown body), "summary" (short snippet), "toc" (heading tree), "structure" (flat section list). binary Default False. Set True to fetch raw bytes (single entry only). main_page Default False. Set True for the archive's main page (zero-path fetch). max_content_length Char cap for view="full" (default 100,000); with binary=True caps fetched bytes (default 10MB, oversize returns metadata + truncated: true). content_offset Char offset into the body for view="full" (default 0). Used with the truncation footer's pass content_offset=N hint. Single-entry only. compact Default False. Set True for small-LLM compaction. (zim_query defaults it True.) compact_budget Inert here — never forwarded. Only zim_query honors it.

RESPONSE: Branch-dependent dict — EntryResponse / BatchEntryResponse / EntrySummaryResponse / TableOfContentsResponse / ArticleStructureResponse / BinaryEntryResponse — or ToolErrorPayload on invalid combinations (invalid_path_combination).

ERRORS: Invalid branch combinations return structured invalid_path_combination; message names the conflict. Defense-in-depth: even if a small model flattens the wire-schema oneOf and sends an impossible payload, the handler rejects it cleanly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNofull
binaryNo
compactNo
main_pageNo
entry_pathNo
entry_pathsNo
zim_file_pathYes
compact_budgetNo
content_offsetNo
max_content_lengthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.2.5

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the readOnlyHint annotation by disclosing truncation behavior, content_offset continuation hints, binary mode's view lock, and the fact that compact_budget is never forwarded. It also explains the structured invalid_path_combination error and defense-in-depth rejection behavior, all of which are valuable for an agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long, but it is densely informative and well-structured with labeled sections: branch summary, aliases, parameters, response, and errors. Every sentence adds necessary call guidance, and the front-loaded overview helps an agent quickly understand the tool's shape.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the RESPONSE section properly enumerates the branch-dependent response types and the error payload. The ERROR section clarifies how invalid combinations are reported, so an agent has sufficient context to invoke the tool and interpret results correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, so the PARAMETERS section carries the full burden. It explains every parameter's role, default, mutual exclusions, and special interactions, such as max_content_length capping bytes when binary=True and view being locked to 'full' in binary mode. This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action and object: 'Fetch entries from a ZIM archive — single, batch, binary, or main page.' It then enumerates the four distinct retrieval modes, making it clear what this tool does and how it differs from searching or querying. The alias list further reinforces the intended purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs the caller to select one of four mutually exclusive branches and details which parameters to pass for each. It also names forbidden combinations, such as non-full views in batch mode and extra parameters in main-page mode. The note that compact_budget is only honored by zim_query provides a clear cross-tool alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools