deepseek_fetch

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds substantial context beyond them: per-call pricing (0.005 CNY), a 15-minute no-double-billing window across paginated reads, that blocked domains incur no request and no charge, and that long pages paginate with a next-page start_index hint. This is exactly the operational detail an agent needs before spending money or retrying.

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?

Purpose and scope are front-loaded in the first sentence, and the remaining sentences each carry load-bearing constraints (billing, blocked URLs, pagination, content stripping). It is dense and bilingual duplication adds length, but almost nothing is filler.

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 still explains what comes back (Markdown body, no links/images, pagination hint in the tail) and what it costs. Combined with the annotations, an agent has everything needed to invoke, cost-anticipate, and continue pagination correctly.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that long pages are read in pages and that the returned tail signals the next page's start_index, which clarifies the pagination contract between max_chars and start_index. The max_chars/start_index mechanics themselves remain with the schema, keeping it short of a 5.

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 opening sentence states a specific verb (fetch) and resource (one web page), plus the exact transform applied (returns Markdown body via DeepSeek). It distinguishes this from a plain fetch by naming scope limits (single page, no intranet/auth URLs) and even routes away from sibling-adjacent scenarios when links/images are needed.

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?

Explicit exclusions are given: no localhost/intranet/password-protected URLs, and named domains (Zhihu/Xiaohongshu/X, Wikipedia, GitHub raw, PDF, NEJM/Lancet) route to other tools without a request or charge. It also states the condition under which the client's own fetch tool should be used instead (when links or images are required), covering both when-to-use and when-not.

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