docs_get_page

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

With no annotations supplied, the description carries the disclosure burden and does fairly well: it states the return format (Markdown), that section extraction returns only a relevant subsection, that full=true returns the entire page, and that maxChars bounds output length. It doesn't say what happens when a section heading is not found or how truncation is signaled, which keeps it below 5.

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?

A single tight paragraph that front-loads the core purpose, then the parameter behaviors, then the budget constraint. Every clause carries information; nothing is padding.

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?

For a four-parameter read tool with no output schema and no annotations, the description covers purpose, source constraints, return format, narrowing options, and a usage budget. Only edge-case behavior for missing sections or truncated results is unaddressed, which is a minor gap.

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%, so all four parameters are already documented in structured form, and the description largely restates them (section as heading/anchor, full as whole page, maxChars as length control). The one added nuance is the origin constraint on url (must come from search_docs hits), but the interaction between section and full is left implicit. Baseline 3 applies 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 opens with a specific verb and resource ("读取一篇资料为 Markdown") and names both supported sources (roboparty.com docs pages and the RP1 GitHub README/docs). It also ties itself to the sibling docs_search_docs by specifying the URL comes from search hits, so an agent can distinguish it from docs_list_toc or docs_list_manuals without inspecting schemas.

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?

It gives clear workflow guidance: pass a URL returned by search_docs, and optionally narrow with section or full. The budget rule ("每个问题最多打开 1–2 篇") is a genuinely useful usage constraint. It stops short of explicitly contrasting when to use this versus docs_list_toc or docs_list_manuals, so it is not a full 5.

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