Skip to main content
Glama
cameronrye

OpenZIM MCP Server

by cameronrye
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

zim_get_section

Read-only

Fetch a specific article section from a ZIM knowledge base by section ID, optionally including subsections, to retrieve only the needed content.

Instructions

Fetch one named section of an article — by section_id (from the TOC), with optional subsection inclusion.

EXTRACT the section id before calling — zim_get(view="toc") lists them if the caller didn't supply one.

ALIASES: callers may say "section of ", "show me the section", " section ". Route through THIS tool.

PARAMETERS: zim_file_path REQUIRED. The archive containing the article. entry_path REQUIRED. The article whose section to fetch. section_id REQUIRED. The TOC id (e.g. "History"). max_chars Optional char cap on the section body. include_subsections Default True: include nested subsections. False: stop at the next heading of any level. compact Default True: oversized tables become placeholders and link markup is stripped (the zim_get compact=True shape). False: raw body with full tables and links. compact_budget Inert — never forwarded. Use max_chars to cap this tool; only zim_query honors this one.

RESPONSE: GetSectionResponse — section body markdown, metadata, and any nested subsections.

ERRORS: Unknown section_id → ToolErrorPayload with available_section_ids (not a hint) and closest_match. Missing entry → entry_not_found.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
compactNo
max_charsNo
entry_pathYes
section_idYes
zim_file_pathYes
compact_budgetNo
include_subsectionsNo

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?

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond by documenting that compact strips link markup and replaces oversized tables, compact_budget is inert and never forwarded, include_subsections=False stops at the next heading, and error payloads expose available_section_ids and closest_match rather than a hint.

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?

Front-loaded purpose, then compact label-style sections for aliases, parameters, response, and errors. Every sentence adds semantic value; the parameter annotations are organized and directly scannable.

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?

For a tool with no output schema and no schema-level parameter descriptions, the response shape and error cases are spelled out. The combination of prerequisites (get section_id from TOC), parameter behavior, response contents, and error payloads leaves no critical gap for correct invocation.

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?

Schema description coverage is 0%, so the description carries the full burden, and it succeeds: all seven parameters are explained, with defaults for include_subsections and compact, and the inert nature of compact_budget is explicitly called out. Error semantics for section_id are also covered.

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 first sentence identifies a specific verb and resource: 'Fetch one named section of an article' by section_id from the TOC, with optional subsection inclusion. This makes it clearly distinct from siblings like zim_get (whole article/TOC) and zim_query.

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?

It explicitly tells the agent to extract section_id before calling and points to zim_get(view='toc') as the source when the caller didn't supply one. The ALIASES block gives concrete caller phrasings and directs routing through this tool, and it warns that compact_budget is only honored by zim_query, so the agent knows not to use it here.

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