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

Split Markdown into chunks

chunk_markdown
Read-onlyIdempotent

Split Markdown files or text into heading-based chunks for search, embeddings, or RAG; each chunk keeps its heading path and line range.

Instructions

Split a Markdown file or Markdown text into chunks by heading, for search, embeddings or RAG.

Use this when you need a long Markdown document (docs, notes, a README) broken into pieces that each know where they came from. A chunk never mixes two sections. Each chunk has heading_path (like ["Guide", "Install"]), anchor (the GitHub-style #link), start_line and end_line (1-based, in the file), part and parts (when a big section had to be split), chars and text. Code blocks and tables are kept whole when they fit; when they don't, each piece gets the fence or table header again. Plain code, not AI: same input, same chunks.

Do not use it for PDF or Word files (convert them to Markdown first), to just see the headings (use outline_markdown), or to read one section (use get_section). Sizes are characters, not tokens.

Returns {"source", "total", "start", "chunks": [...], "next_start"}. next_start is null when there are no more chunks.

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.
limitNoMost chunks to return in one call. Default 100.
startNoFirst chunk number to return (1 = the first). Use next_start from the last call to get more.
max_charsNoBiggest chunk size in characters (not tokens). Default 1500.
prefix_pathNoIf true, each chunk text starts with its heading path, like "Guide > Install".
overlap_charsNoCharacters repeated from the end of one part at the start of the next, only when a section is split. Must be at most half of max_chars. Default 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavior beyond them: chunks never mix sections, code blocks and tables stay whole, split pieces get the fence or table header repeated, and output is deterministic ("same input, same chunks"). It also notes units are characters, not tokens, and describes pagination via next_start.

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?

It is front-loaded with the core purpose and the disambiguation rules, and most sentences carry information an agent needs. It is on the long side for a tool whose schema is fully documented, with some density that could be trimmed, but nothing is filler.

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?

Despite having seven parameters and no output schema, the description enumerates the chunk fields (heading_path, anchor, start_line, end_line, part/parts, chars, text) and the envelope keys including next_start. An agent has everything needed to call it and to interpret the response.

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 all seven parameters are already well documented upstream; this sets the baseline at 3. The description reinforces that sizes are characters rather than tokens, but adds no new syntax, format, or interaction details for path/text, limit, start, prefix_path, or overlap_chars.

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 states a specific verb and resource ("Split a Markdown file or Markdown text into chunks by heading") and immediately names the intended application (search, embeddings, RAG). It is clearly distinguishable from siblings: outline_markdown is for headings only and get_section for reading a single section.

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 gives an explicit when-to-use sentence (long docs, notes, READMEs needing provenance-aware pieces) and explicit when-not conditions: no PDF/Word, use outline_markdown to list headings, use get_section to read one section. Alternatives are named with the condition that selects them.

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