Skip to main content
Glama
Sign In
io.github.tidybytetools/md-chunk-lite

io.github.tidybytetools/md-chunk-lite

Official
by tidybytetools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get one Markdown section

get_section
Read-onlyIdempotent

Retrieve a single Markdown section by heading title or anchor to read only the needed part of a long document instead of the whole file.

Instructions

Return the text of one section of a Markdown file or text, found by heading title or anchor.

Use this when you only need one part of a long document, like the "Install" section of a README, so you don't have to read the whole file. If two headings have the same title, the first one is returned and "matches" tells you how many there are; use the anchor (from outline_markdown) to pick another.

Do not use it to split the whole document (use chunk_markdown).

Returns {"title", "heading_path", "level", "anchor", "start_line", "end_line", "chars", "matches", "text"}. If nothing matches, the error lists the headings.

Input Schema

NameRequiredDescriptionDefault
pathNoFull path to a local Markdown or text file (UTF-8, up to 10 MB). Leave empty if you pass text.
textNoMarkdown text to use instead of a file. Leave empty if you pass path.
anchorNoAnchor to find, like "install" or "install-1" for the second "Install". Wins over heading.
headingNoHeading title to find, like "Install". Not case sensitive. Leave empty if you pass anchor.
include_subsectionsNoIf true (default), include the smaller headings under it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds genuine behavior the agent could not infer: duplicate headings resolve to the first match with a "matches" count, and a failed lookup returns an error that lists available headings. It also enumerates the return keys, which matters because there is no output schema. It stops short of describing subsection expansion behavior in prose, leaving that to the schema.

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 tight paragraphs ordered by importance: what it does, when to use and when not to, then return/error shape. No filler sentences and no restatement of the title.

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?

With no output schema, the description compensates by listing the exact return fields and describing the no-match error, plus the duplicate-heading edge case. An agent has everything needed to call it correctly and interpret the result.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds meaning beyond the schema by explaining the interplay between heading and anchor for duplicate titles and what "matches" means in the result. The anchor/heading precedence is already documented in the schema, so that portion is repetition rather than added value.

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 gives a specific verb (return the text), a scoped resource (one section of a Markdown file or text), and the selection mechanism (heading title or anchor). This clearly separates it from chunk_markdown, which is named explicitly as the whole-document alternative.

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 states when to use it with a concrete example (the "Install" section of a README) and states when not to use it, naming the sibling to use instead (chunk_markdown). It also gives a fallback path for the ambiguous case: use the anchor from outline_markdown when duplicate headings exist.

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