Reads a previously exported article as paginated Markdown without re-fetching the webpage, returning next_offset and image paths to continue reading and view figures.
读取本工具已导出的文章全文，不重新请求网页。返回 Markdown 正文片段、next_offset、图片路径和警告。next_offset 为 null 时读完；需要查看图表时打开 images[].read_path。
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | 正文字符偏移；首次为 0，后续使用 next_offset。 | |
| json_path | Yes | web_to_readable 返回的 json_path。 | |
| max_chars | No | 每次最多读取字符数。 |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value not in structured fields: it names the returned payload (Markdown fragment, next_offset, image paths, warnings) and gives the termination condition (next_offset null) plus how to reach figures via images[].read_path, which matters because there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with no wasted words: identity/scope first, then return payload, then the termination and image-access instructions. Front-loaded and every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully explains return values, pagination termination, and image access, which is sufficient to call the tool correctly. It does not describe the warnings field's content or error cases, a minor residual gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself documents offset, json_path and max_chars including the next_offset continuation hint. The description adds only the implicit link between next_offset and the offset parameter, so it does not meaningfully exceed the baseline when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource ('读取本工具已导出的文章全文') and explicitly clarifies it does not re-request the webpage, which cleanly separates it from the sibling web_to_readable that performs the fetching. An agent can distinguish the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'不重新请求网页' implies the correct choice versus re-fetching via web_to_readable, and the offset/next_offset flow defines the iterative usage pattern. It stops short of explicitly naming when to call web_to_readable first, so it is clear context but not a full when/when-not routing rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.