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

No annotations are provided, so the description carries the burden. It does disclose the currency units and the split between granted and topped-up balance, which is useful. However, it does not state whether authentication/API key is required or whether the call is read-only (implied but not declared).

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 sentence, front-loaded with the verb and resource, with the currency/breakdown detail trailing. No waste.

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?

An output schema exists, so return values need not be explained. For a zero-parameter read-only balance check, the description gives all an agent needs to select and invoke it 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?

There are zero parameters, so the baseline is 4 by rule. The description adds nothing parameter-related, and nothing is needed.

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 (check) and resource (DeepSeek account balance) and even names the returned breakdown (granted vs topped-up, CNY and USD). Clearly distinguishable from all siblings, which are search/fetch/research tools.

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 strongly implied: this is the only account/balance tool among search and fetch siblings, so an agent can infer when to call it. But there is no explicit when-to-use/when-not-to-use statement or named alternative.

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?

With no annotations, the description carries the full burden and does so: known 404 and timeout cases, ~30 minute in-memory cache with concurrent-call dedupe, a local per-endpoint rate limit with the rate_limited_local error code, a 32 MiB response_too_large cap, and ssrf_blocked rejection of internal hosts, private addresses and credentialed URLs before any request. It also warns that the return payload omits final URL, status and date, telling the agent to preserve provenance itself.

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 purpose and return shape, then caveat, then cache/limit behavior, then Args. Dense but zero filler: every sentence either routes the agent or prevents a specific failure mode.

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?

Covers the whole call lifecycle for a four-parameter fetch tool: eligibility (SSRF, URL length), known failure modes with error codes, caching semantics, and the limits of the returned payload. Even though an output schema exists, the note about missing provenance fields is advisory context the schema would not supply.

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 0%, so the description must compensate and it does: url is bounded ('absolute http(s) URL, max 8192 characters'), clean explains the specific DeepSeek escaping artifacts it strips, max_chars is pinned to 'applied after cleaning', and refresh is tied to the cache flag in the envelope. Only minor gap is that defaults for clean/refresh/max_chars are left to the schema.

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?

Opens with a specific verb and scope ('Fetch one known URL') plus what comes back ('title and Markdown content'), which cleanly separates it from deepseek_web_search, deepseek_search_and_read and deepseek_fetch_many. The single-URL scope is stated explicitly, so an agent can pick this tool without opening any 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 an explicit when-not rule with the failure conditions spelled out (PDFs and Reddit return 404, some sites time out) and names the exact alternative plus the query shape to use there ('deepseek_search_and_read with the page title or a site:-scoped query'). Routing is fully determined, not inferred.

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?

With no annotations, the description carries the full burden and does so thoroughly: shared 120s deadline, cancellation with deadline_exceeded, per-URL failure isolation, duplicate/empty handling, cache interaction, and the top-level ok vs partial distinction. That last point in particular prevents a real misread of batch success.

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 capability, then behavior, then Args – a sound structure with little waste. The paragraph enumerating every envelope field is somewhat redundant given an output schema exists, which is the only thing keeping this below a 5.

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 5-parameter concurrent batch tool with no annotations, this covers the edge cases an agent must reason about: partial failure, deadline truncation, truncation notes, and per-item cache flags. Nothing needed to call 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?

Schema coverage is 0%, yet the Args block gives meaning to all five parameters: the 1-10 / 8192-char URL bounds, the purpose of max_chars_per_url and max_total_chars, and what clean and refresh actually change. The allocation formula min(max_chars_per_url, max_total_chars // count) is semantics the schema cannot express at all.

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, resource, and cardinality bound ('Fetch up to 10 known URLs concurrently') plus the return shape (page title and Markdown content). The 'known URLs' phrasing and the explicit reference to deepseek_fetch's validation pipeline make the boundary with the single-URL sibling clear.

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?

'Known URLs' implicitly steers the agent away from this tool for discovery (deepseek_web_search/deepseek_research), and the deepseek_fetch reference establishes the shared pipeline. However, it never states explicitly when to pick this over calling deepseek_fetch repeatedly, leaving that inference to the reader.

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?

With no annotations, the description carries the full behavioral burden and does so: it explains the fallback fetch path, the 200-character/URL-validation triggers, the 5-fetch cap, that failures keep search content and set error while the call still returns partial=true, cache-hit accounting in requests_used/cached_count, and truncation notes. Nothing important about failure modes or side effects is left implicit.

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?

It is front-loaded with the core action and organized into behavioral paragraphs followed by args, which is good. However, the sentence enumerating every source field (id, title, url, authority, rerank_score, content, chars, origin, error, cached) largely restates the output schema and adds bulk without new decision-relevant 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?

For a 5-parameter tool with a multi-stage search-and-fetch pipeline and partial-failure semantics, the description covers trigger conditions, budget capping, caching, error propagation, and counting fields. Combined with an existing output schema, an agent has everything needed to call it correctly and interpret the result.

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 0%, so the description must compensate, and it largely does: question gets a 128-character limit plus supported operators (site:, -site:, "phrase", lang:), max_pages gets the 1-50 range and default 5, and refresh is defined as bypassing caches for both search and fetches. per_page_chars and total_chars are only described as caps without ranges, which is the remaining gap.

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 and resource plus the internal workflow: 'Gather source material for a question: one search with page content, then fetch the gaps.' It also disambiguates from siblings by declaring 'no query rewrite, no model call, no summary', which separates it from the search-and-read style tools listed alongside it.

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?

'Synthesis is left to the caller' establishes the boundary of responsibility, and the search-then-fetch-gaps framing tells an agent when this pipeline is the right shape. It stops short of explicitly naming deepseek_web_search or deepseek_search_and_read as alternatives with selection criteria, so no exclusion rules are given.

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?

With no annotations, the description carries the full burden and does so well: in-memory caching window, concurrent-call coalescing, the `cached` envelope flag, per-endpoint local rate limiting with the specific `rate_limited_local` error, and an 8 MiB `response_too_large` ceiling. These are exactly the runtime traits an agent needs to retry or budget correctly.

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?

The recommendation and the one-request framing are front-loaded, followed by operational behavior, then an Args block — a sensible order. The benchmark anecdote (14 questions, ~0.7s/call) is slightly padded but does real work justifying the recommendation.

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?

An output schema exists, so return values need not be explained, and the description still flags the `cached` envelope field. For a 9-parameter retrieval tool with no annotations, the mix of routing guidance, failure modes, and per-argument behavior leaves nothing an agent needs 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?

Schema coverage is 0%, so the description must compensate — and it documents all nine parameters with behavior the schema cannot express: count interacts with dedupe (extras requested upstream), rewrite is skipped when lang is set and falls back silently, refresh bypasses cache, lang is a language operator with a test-with-and-without heuristic for named entities, plus the two char budgets.

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?

Opening line states a specific verb and resource plus the key differentiator: search *and* full page content in a single request. It also equates itself to a known primitive ('search with need_content=True') and names the sibling it outperforms (deepseek_fetch), so an agent can place it immediately.

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?

Calls itself 'the recommended retrieval path' and gives concrete evidence for preferring it over deepseek_fetch (PDFs/Reddit where fetch returned 404). It does not, however, state when to prefer deepseek_web_search (metadata-only) or deepseek_fetch_many, which are the closest alternatives in the sibling list.

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?

No annotations are provided, and the description carries the full load well: memory caching with a cached flag, deduped concurrent request sharing, local per-endpoint rate limiting with the rate_limited_local error code, an 8 MiB response_too_large failure mode, and rewrite being skipped when lang is set with silent fallback. These are exactly the operational traits an agent needs before invoking.

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?

The prose preamble is front-loaded and dense with useful content, but the trailing Args block restates the lang guidance almost verbatim ("For non-English queries set it to the appropriate code; without it results may be mixed-language. For named entities test with and without the operator"), which appears twice. Redundant rather than bloated, so minor deduction only.

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 10-parameter search tool with no annotations, the definition covers invocation semantics, cost/alternative tradeoffs, failure codes, and even result field meanings (date RFC 3339, authority 0-4 with -1 unknown). An output schema exists so return-value structure needn't be spelled out, and nothing needed to call 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?

Schema description coverage is 0%, so the description must compensate, and it does: every one of the 10 parameters is documented with bounds (query max 128 chars, count 1-50 default 10), supported query operators (site:, -site:, "phrase", lang:, after:, before:), and defaults (dedupe on, rewrite off, refresh false). It also explains secondary effects, e.g. that dedupe causes extras to be requested upstream so duplicates don't leave you short.

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?

Opens with a specific verb+resource ("Search the web with DeepSeek's index") and immediately states what comes back (titles, URLs, dates, authority and rerank scores). It also distinguishes itself from the sibling deepseek_fetch by positioning this tool as the discovery/ranking entry point, so an agent can pick it without opening any 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?

Explicitly says what to use it for ("discovery and ranking") and names the alternative plus the decision rule: set need_content=True to avoid "calling deepseek_fetch afterwards" because it is "cheaper and more reliable." It also gives conditional guidance for lang (non-English queries) and for named entities (test with and without the operator).

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