Marten Docs MCP Server

read_section

Read-onlyIdempotent

Retrieve a paginated chunk of documentation content by section ID. Specify offset, maximum characters, and segment index to continue reading from a previous search result.

Instructions

Read one chunk with pagination. Prefer neighbors.before/after for the next local read before running another global search.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "read_section"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes
`offset`	No
`maxChars`	No
`segmentIndex`	No

Output Schema

Name	Required	Description	Default
`id`	No
`path`	No
`error`	No
`kinds`	No
`title`	No
`segment`	No
`headings`	No
`neighbors`	No
`pageOrder`	No
`segmentCount`	No
`firstCodeIndex`	No
`resolvedSegmentIndex`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.8Aug 18, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is clear. The description adds that the tool reads a single chunk with pagination, which is consistent with the hints and clarifies the paginated nature beyond what annotations provide. A minor deduction because the description doesn't mention any side effects or return structure, but overall it's very transparent.

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?

The description is two sentences, zero wasted words. The first sentence states the core function, the second provides strategic guidance. Every sentence earns its place.

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?

Given the annotations (readOnly, idempotent, openWorld), the presence of an output schema (handling return structure), and the clarity of purpose/usage, the description is nearly complete. The only gap is not explaining the parameter roles in detail, but the output schema likely covers return values. A score of 4 reflects that it's well-suited for a tool with good structural support.

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 description coverage is 0%, so the description must compensate. Although the description doesn't detail each parameter, it effectively implies the core usage (read a chunk, pagination) which orients the agent. For 4 parameters with no schema descriptions, this is adequate to infer most parameter purposes, though specifics like offset vs. segmentIndex aren't explained.

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 starts with 'Read one chunk with pagination', which uses a specific verb and resource, and the context about preferring neighbors.before/after distinguishes it from sibling tools like search_docs or list_headings.

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?

The description explicitly tells the agent when to use this tool ('prefer neighbors.before/after for the next local read before running another global search'), effectively contrasting it with alternatives and providing a clear usage strategy.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server