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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new operational context: it requires DEEPSEEK_API_KEY and takes no arguments, and that telemetry is in-memory (session-scoped, likely not persisted). It stops short of noting that the balance portion makes an authenticated network call that can fail on missing/invalid keys.

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 primary verb+resource and kept to three short sentences. The second sentence partially restates the first ("Verify account funds and monitor session usage" vs the opening line), which is mild redundancy but also serves as the usage statement.

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 no-argument read tool with an output schema, everything essential is present: purpose, auth prerequisite, arity, and routing away from siblings. The only soft spot is "in-memory session telemetry", which leaves ambiguous whose session is measured and when the counters reset.

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?

Zero parameters, so the baseline is 4. The description reinforces this with "Takes no arguments", which prevents an agent from hunting for a currency or session-id parameter that does not exist.

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 pair ("Check DeepSeek account balance (CNY/USD)") plus a second explicit capability ("in-memory session telemetry"), and names the sibling tools it is not for. An agent can distinguish it from the deepseek_search/fetch family 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 explicit positive context ("Verify account funds and monitor session usage") and an explicit exclusion with named alternatives: "Do not use for search or retrieval (use deepseek_search or deepseek_fetch)". Both when-to-use and when-not-to-use are covered.

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 already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the internal pipeline (subquery decomposition, concurrent retrieval, citation markers [1],[2]) and the caching behavior implied by the refresh parameter. It stops short of stating cost, latency, or failure modes for a tool that fans out multiple network calls, which is the one remaining gap.

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 a one-line purpose, then usage rules, then a compact Args block. Every line carries information — no restatement of the tool name, no filler prose.

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 needn't be explained, and the parameter section compensates fully for the 0% schema coverage. Purpose, routing, and per-argument semantics are all present for a 7-param tool, leaving nothing an agent would need to guess before calling it.

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 carry the full burden and it does: all seven params are documented with meaning, ranges (topic max 500 chars, max_queries 2-4, max_pages_per_query 1-5), defaults (3, 3, True, False, True), and an example value for lang ('en', 'pl'). This is information the schema alone does not convey.

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: 'Execute multi-angle research on a topic and generate a cited briefing report.' The second sentence explains the mechanism (decompose into subqueries, concurrent retrieval, synthesized cited report), which distinguishes it from the plain search/fetch siblings.

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 routes the agent: 'Use for deep topic synthesis. Do not use for simple lookups (use deepseek_search/deepseek_research) or reading known URLs (use deepseek_fetch).' Both exclusions and named alternatives are given, so nothing is left to inference.

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 already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds value beyond that: it states the result is returned under 'data', that full page text is not returned, that caching exists and can be bypassed via refresh, and that escapes/boilerplate are cleaned by default. Missing only rate limits, auth/cost behavior, and extraction failure semantics.

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 sibling routing are front-loaded in the first paragraph, followed by a compact Args list where each line carries distinct information. The only waste is echoing defaults already visible in the schema and one near-tautological parameter gloss.

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-value detail is not required, yet the description still tells the agent where the payload lives ('data'). Combined with the field/schema exclusivity rule and the cache/fetch controls, an agent has everything needed to 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?

Schema coverage is 0%, so the description carries the full burden and does document all eight parameters with intent, not just names — notably the mutual exclusivity of fields and schema, which the schema does not express at all. Defaults are restated (clean, max_chars, refresh, strip_boilerplate), which is mildly redundant, and a couple of glosses are thin ('schema: JSON Schema defining target structure', 'instruction: Optional extraction guidance').

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 names a specific verb (extract), a specific resource (web page), and a specific output shape (structured JSON conforming to fields or a schema). It further scopes the tool negatively ('without returning full page text'), so an agent can distinguish it from deepseek_fetch and deepseek_search 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?

Explicit exclusions are given with named alternatives: 'Do not use for general reading (use deepseek_fetch), nor for search or discovery (use deepseek_search).' This is exactly the when-not/alternative routing an agent needs, and it names two of the six siblings directly.

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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: caching with a refresh bypass, content caps, escape-cleaning, boilerplate stripping, and a concrete failure mode (404 on PDFs/Reddit). It stops short of describing pagination or what 'sections' look like structurally.

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 one-line purpose and the routing sentence, then the arg list. The Args block is long but each entry earns its place given 0% schema coverage. Minor duplication between the opening line and the second sentence ('Fetch one known URL' / 'Retrieves full Markdown content for a known URL').

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 needn't be explained, and the description states them anyway (title + Markdown). With 8 params, an open-world network dependency, and a known failure mode, the definition gives an agent nearly everything needed to call correctly. It could go slightly further on cache staleness semantics for refresh/section interplay.

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 carries the full burden, and it does: every one of the 8 params is documented with defaults and constraints (url absolute http(s) max 8192 chars, max_snippets 1-5, section 1-based, clean removes backslash escapes, max_chars applies after cleaning). That is materially more than the bare titles and defaults in 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?

States a specific verb and resource ('Fetch one known URL') and explicitly names the output ('its title and Markdown content'). The pairing with sibling names in the next sentence lets an agent distinguish deepseek_fetch from deepseek_fetch_many 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?

Gives an explicit selection condition ('Use when target URL is known') plus a per-alternative routing map: fetch_many for multiple URLs, extract for structured data, search for search. It even names a carve-out case (PDFs/Reddit return 404, use deepseek_search instead), which is exactly the kind of when-not guidance that prevents wrong selection.

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 already declare readOnly/idempotent/openWorld/non-destructive, and the description still adds real behavior: blank-skipping, deduplication, order preservation, cache bypass via refresh, cancellation of pending fetches at the deadline, and per-page plus global content budgets. It stops short of saying what happens when individual URLs fail (partial results vs. whole-call error), which is the main behavioral gap for a concurrent fetch tool.

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 statement and the use/do-not-use routing before the Args block, so an agent gets the decision-relevant information first. The opening two sentences are somewhat redundant ("Fetch up to 10 known URLs concurrently" / "Fetch multiple known URLs in parallel"), costing a little space without adding 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 an output schema present, the description needn't explain return values, and it covers routing, all 8 parameters, budgets, caching, and timeout behavior for a moderately complex tool. The remaining unknown (per-URL failure semantics) is secondary to correct invocation.

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 carry all parameter meaning, and it does document all 8 including defaults and constraints (1–10 absolute http(s) URLs, 8192 chars each, default budgets). The weakest entry is `query`, described only as "extract ranked snippets across fetched pages," which doesn't make clear whether it changes the return shape or filters content.

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 (fetch), resource (up to 10 known URLs concurrently), and even the return shape (each page's title and Markdown content). It explicitly contrasts itself with deepseek_fetch and deepseek_search, so an agent can distinguish it from siblings without opening a 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 positive condition ("Use when target URLs are known") and two explicit exclusions with the named alternatives to use instead (single URL → deepseek_fetch, search/discovery → deepseek_search). Nothing is left to inference.

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 already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description still adds real value beyond that: exactly one search, no query refinement or summarization, raw content returned to the caller, parallel auto-fetch of stub pages, and cache-bypass via refresh. It stops short of anything on rate limits, failure/partial-result behavior, or what happens when stub fetches fail, so it is good but not fully transparent.

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 is front-loaded and tight — purpose, non-behavior, sibling contrast, then the parameter block. The only waste is mild redundancy in restating defaults (5, 6000, 30000, True/False) already present in the schema, though the added ranges and examples justify most of the repetition.

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 an output schema present, return values need no explanation, and annotations cover the safety profile. What remains — single-pass semantics, raw-content contract, cache and dedupe behavior, and full parameter meaning — is all covered, so an agent has everything needed to call this 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 description coverage is 0% and there are 13 parameters, so the description carries the full burden — and it does, documenting every parameter with units and constraints ('max 128 characters', '1-50 (default 5)', date formats 'YYYY-MM-DD/YYYY', domain list examples, language codes). This is exactly the compensation the low coverage requires.

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 line gives a specific verb and resource ('Single-pass source gathering: search with page content and auto-fetch stub pages') and the second sentence scopes the behavior ('Gathers candidate sources for research'). It explicitly contrasts itself with the named sibling deepseek_search ('index-only'), so 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?

It states the selection condition directly: 'Use when research requires complete documents rather than snippets,' and names the alternative (deepseek_search) that covers the snippet case. The 'does not iterate, refine the query or summarise' clause implicitly routes multi-pass work away from this tool, giving both a when and a 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the safety profile is covered structurally. The description adds meaningful non-annotation context: a response cache that refresh bypasses, optional query rewriting via deepseek-flash, dedupe collapse behavior, and boilerplate stripping. It does not mention rate limits, cost, or failure/fallback behavior, keeping it below a 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?

The purpose, primary-use statement, and sibling differentiation are front-loaded in three tight sentences, then a compact Args block. Every line earns its place, though the Args list at 16 entries makes the whole thing long; the leading prose could be trimmed slightly without loss.

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 16-parameter tool this is thorough: ranking modifiers, content-vs-snippet mode, char budgets, domain filters, date filters, and cache control are all explained. An output schema exists, so return-value explanation is correctly omitted, and nothing an agent needs 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?

Schema description coverage is 0%, so the description bears the full burden, and it documents all 16 parameters with defaults, ranges, and formats (count 1-50 default 5, date formats YYYY-MM-DD/YYYY, query operators site:/after:/before:, example domain lists). This meaningfully exceeds what the bare schema conveys.

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 first sentence names a specific verb (search) and resource (web via DeepSeek index) plus the return shape (page text, snippets, metadata). It explicitly states 'Primary search and retrieval tool for AI agents' and contrasts itself with the deepseek_research sibling, so an agent can distinguish the two 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 names a positive context ('Use for standard search, targeted queries, and discovery') and gives an explicit differentiation rule versus deepseek_research ('auto-fetches stub pages' vs 'only returns indexed content'). It stops short of naming when to prefer deepseek_fetch, deepseek_fetch_many, or deepseek_extract for known-URL retrieval, leaving some routing to inference.

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