Skip to main content
Glama
jgravelle

jdocmunch-mcp

by jgravelle
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_section

Read-only

Retrieve the full content of a specific section using byte-range reads. Use after identifying section IDs via search_sections or get_toc. Returns this section's own bytes; nested child sections are not included.

Instructions

Retrieve the full content of a specific section using byte-range reads. Use after identifying section IDs via search_sections or get_toc. Returns this section's own bytes; nested child sections are not included. A section with text_source="ocr" was read from a scanned page by OCR: its text may contain errors, and tables or forms in it may be scrambled.

Input Schema

NameRequiredDescriptionDefault
repoYesRepository identifier
verifyNoVerify content hash matches stored hash (detects source drift)
section_idYesSection ID from get_toc, search_sections, or get_document_outline. v1.147+ — also accepts a `doc.md#anchor` reference to a heading written with an explicit `{#id}`; an ambiguous reference sets `anchor_ambiguous`, `anchor_scope`, `anchor_match_count` (uncapped), `sections` (bodies for the first 5 matches only), `sections_truncated`, `anchor_candidates` (at most 20), `anchor_candidates_truncated` and `warning`.
compress_codeNov1.35+ — when true, drop blank lines and full-line comments inside fenced code blocks before returning. _meta.code_compressed_bytes reports bytes saved.
strip_boilerplateNov1.24+ — when true, suppress repeated cross-section fragments (footers, nav, license headers) before returning content.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.147.0
    • changedInput schema / properties / section_id / description
      Previous value: -"Section ID from get_toc, search_sections, or get_document_outline"New value: +"Section ID from get_toc, search_sections, or get_document_outline. v1.147+ — also accepts a `doc.md#anchor` reference to a heading written with an explicit `{#id}`; an ambiguous reference sets `anchor_ambiguous`, `anchor_scope`, `anchor_match_count` (uncapped), `sections` (bodies for the first 5 matches only), `sections_truncated`, `anchor_candidates` (at most 20), `anchor_candidates_truncated` and `warning`."
  2. Addedv1.118.0
  3. Removedv1.99.0
  4. First observedv1.66.3

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare readOnlyHint; the description adds real context beyond that: partial-read semantics (own bytes only, children excluded), and the OCR caveat that text_source='ocr' content may contain errors and scrambled tables/forms. It doesn't cover error behavior or size/truncation limits.

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?

Three short sentences, front-loaded with the core action, then the ID-discovery prerequisite, then the child-exclusion rule and OCR caveat — every sentence carries distinct information.

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

Completeness4/5

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

With no output schema, the description adequately covers scope, prerequisites, and a return-quality caveat (OCR). Minor gap: no mention of response size limits or behavior on missing/invalid section_id, which matter for a byte-range fetch.

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

Parameters3/5

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

Schema description coverage is 100%, so verify, compress_code, strip_boilerplate and section_id are fully documented in the schema. The description adds only the OCR/text_source hint and no additional parameter guidance, so baseline 3 applies.

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?

States a specific verb and resource ('Retrieve the full content of a specific section') and adds mechanism ('byte-range reads'), plus scoping ('Returns this section's own bytes; nested child sections are not included'), which distinguishes it from get_section_descendants/get_sections.

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

Usage Guidelines4/5

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

Explicitly gives the prerequisite flow: 'Use after identifying section IDs via search_sections or get_toc.' Scope exclusion of child sections further implies when to pick a different tool, though no sibling is named directly as an 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