Skip to main content
Glama
jgravelle

jdocmunch-mcp

by jgravelle
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_toc_tree

Read-only

Retrieve a nested table of contents tree per document, showing parent and child heading relationships without content. Use it to navigate docs by section and locate headings without reading full files.

Instructions

Get a nested table of contents tree per document. Shows parent/child heading relationships. Content is excluded.

Input Schema

NameRequiredDescriptionDefault
repoYesRepository identifier (owner/repo or just repo name)
limitNov1.147+ — return at most this many documents (a document's tree is never split), starting at offset. Default: all, subject to the response ceiling (JDOCMUNCH_RESPONSE_MAX_BYTES, 1 MiB), over which the call is refused, never truncated. documents_total, documents_truncated and next_offset are always present.
offsetNov1.147+ — documents to skip. Pass the previous response's next_offset. Default 0.
path_globNov1.36+ — fnmatch glob restricting results to matching doc_paths. Default: no filter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.147.0
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "v1.147+ — return at most this many documents (a document's tree is never split), starting at offset. Default: all, subject to the response ceiling (JDOCMUNCH_RESPONSE_MAX_BYTES, 1 MiB), over which the call is refused, never truncated. documents_total, documents_truncated and next_offset are always present.",
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "v1.147+ — documents to skip. Pass the previous response's next_offset. Default 0.",
+  "minimum": 0,
+  "type": "integer"
+}
  2. Addedv1.118.0
  3. Removedv1.100.0
  4. First observedv1.66.3

TDQS

B3.2/5.0
Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read. The description then adds genuinely useful scope information — 'Content is excluded,' i.e. headings only, no body text — which is not inferable from annotations or schema. It stops short of describing the shape of returned tree nodes, which matters since no output schema is present.

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

Conciseness4/5

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

Three short sentences, front-loaded with the core verb and resource, no filler. 'Shows parent/child heading relationships' mildly restates 'nested' from the first sentence, a small redundancy, but the size is well matched to the tool.

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

Completeness3/5

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

The read-only nature and content-exclusion are covered, and pagination is fully specified in the schema, but with no output schema the description should say something about the returned tree structure (e.g. node fields such as heading title, depth, or path) so the agent knows what it will parse.

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%, and the parameter docs are unusually rich (version gates, offset/limit semantics, next_offset, the 1 MiB response ceiling with refusal-not-truncation). The description adds nothing beyond that, so the baseline 3 applies.

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

Purpose4/5

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

States a specific verb and resource ('Get a nested table of contents tree per document') and adds the structural trait (parent/child heading relationships, content excluded). However, it does not distinguish itself from close siblings like get_toc or get_document_outline, so an agent must still infer which TOC-shaped tool to pick.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no mention of alternatives such as get_toc or get_document_outline, despite three TOC/outline-style siblings existing. The only usable cue is the implicit scope of 'per document,' which is not framed as a selection condition.

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