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.

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

Goes well beyond the readOnly/openWorld annotations: per-call pricing (0.005 yuan, independent of count), approximate total output size (~20k chars), the shrinkage of per-result content as count grows, default doc-farm filtering with named sites, DeepSeek-native result ordering, and the caveat that score/authority are only advisory. These are exactly the operational facts an agent needs before calling.

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?

Front-loaded with the core purpose and dense with useful detail, but the opening sentence is duplicated bilingually and the syntax list is a little sprawling. Almost every line earns its place, with minor redundancy.

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 correctly takes on return-value semantics: result ordering, the meaning of score/authority, and the 'date unknown' labeling for undated results. Combined with the pricing and size notes, nothing needed to invoke it correctly is missing.

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?

Even though schema coverage is 100%, the description substantially enriches every parameter: it enumerates query syntax (site: with OR, -site:, quotes as a weak constraint, lang:, after:/before:), explains the cost/size tradeoff of include_content, and names what exclude_doc_farms actually removes. This is real meaning beyond the terse schema strings.

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?

States a specific verb and resource ('Search the web'), and implicitly distinguishes itself from the sibling deepseek_fetch by noting that include_content is 'cheaper and faster than fetching each result individually'. An agent can tell what this tool does without opening the 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?

Gives concrete practical guidance with conditions: add lang:zh for Chinese searches, use site:github.com to find libraries, add -site:edu.cn to avoid university press releases, and recommends count<=10 when include_content is on. It names the fetch alternative, though it never states an explicit when-not-to-use condition.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description is consistent with that, adding that the data is local (本机) and covers billed call counts, estimated cost, and an anti-overcharge cap. This adds useful context beyond the annotations about what the tool surfaces, though it does not describe the time window or freshness of the statistics.

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 front-loaded sentence listing exactly the three returned data categories, with no filler or redundant restatement of the tool name.

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 and no annotations covering return values, the description must explain what comes back, and it does — call count, estimated cost, and cap. Combined with readOnlyHint/openWorldHint annotations, this is nearly complete, with only the reporting period left unspecified.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly implies no input is needed to retrieve the usage summary.

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 names a specific verb (查看/view) and a specific resource (本机 DeepSeek 计费调用次数、估算花费、防误扣上限), making the tool's output concretely identifiable. It is clearly distinct from the deepseek_search and deepseek_fetch siblings, which perform actions whereas this reports billing state, though it does not explicitly name them.

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?

Usage is implied by the nature of the tool — you call it to inspect local DeepSeek billing/usage — but there is no explicit statement of when to use this versus the search/fetch siblings, nor any prerequisites or exclusions. Adequate but leaves routing to inference.

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