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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the multi-stage pipeline (config generation, execution, failure self-repair) and that output is structured, but says nothing about latency, cost, terminal-failure behavior when self-repair is exhausted, or whether any state is persisted.

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?

Two compact sentences: the capability pipeline is front-loaded, then the audience qualifier. Nothing is redundant and no sentence restates the schema.

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 three simple parameters and full schema coverage, the input side is well covered. However, there is no output schema, so the vague claim "返回结构化结果" leaves the shape of the returned data undefined for an agent that must decide whether the result is usable — a gap that should have been spelled out.

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 three parameters (description, limit, rounds) are already documented in the schema, including the retry semantics of rounds and an example task string. The description adds no format or syntax guidance beyond what the schema already supplies, so the baseline 3 applies.

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 states a specific verb chain (auto-generate config → auto-run → self-repair) and resource (crawler task) plus a structured return, which is far more specific than the ambiguous name 'auto'. It implicitly distinguishes itself from config-driven siblings like scrape/crawl by targeting users who "不会写选择器/配置", but it never names those siblings explicitly.

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 an explicit target-user condition — "适合：不会写选择器/配置的非技术用户" — which tells the agent this is the zero-config entry point. It does not name alternatives (scrape, crawl, extract) or state when NOT to use this tool, so routing still requires the agent to infer from sibling names.

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 it does well: it discloses the failure contract (status=NO_DATA/PARTIAL with per-item diagnostics and an action plan) and explicitly says it will not fake success. It also constrains scope and repeats that login/paywalls are not bypassed. It stops short of stating auth requirements or the mechanism behind the interval-based throttling.

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 leads with the core action and then lists the outputs, and every clause in the one-block description earns its place: scope, exclusion, exports, and failure semantics. It is dense but not padded.

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?

There is no output schema, yet the description names the exact returned files and the NO_DATA/PARTIAL status values, so an agent can anticipate the return shape. Combined with schema-covered parameters, an agent has nearly everything needed to call it, though it does not describe the spec JSON contract or how covers are stored.

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 five parameters, including the nested spec object, are already documented in the schema. The description adds domain color (comparing JD and Dangdang, exporting booklist.csv/md/json) but no syntax or format guidance beyond what the schema provides, so the baseline 3 applies.

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 and resource: it collects book-catalog data from an ISBN list (Douban ratings, author, publisher, JD+Dangdang price comparison) and exports four named file types. That detail differentiates it sharply from generic siblings such as scrape, crawl, and bulk_scrape, which do not mention books or export formats.

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 input shape context (an ISBN list) and the output artifacts, plus clear scope exclusions: no e-book/PDF downloading and no login or paywall bypass. It does not explicitly say when to prefer this over scrape or bulk_scrape, so the sibling routing is implied rather than stated.

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 it does substantial work: per-URL failure isolation ('one URL error doesn't affect the rest'), a default of 10 and hard cap of 30, and a politeness interval. It stops short of explaining what happens past the cap (truncation vs. error), per-request timeouts, or total runtime for a 30-URL batch.

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?

Four tightly packed clauses, front-loaded with the core value proposition and then the safety limits and return shape. Each clause carries distinct information (batch economics, failure isolation, caps, politeness, output) with no 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?

For a 6-parameter batch tool with no output schema and no annotations, the description covers the essential behaviors: batching, isolation, caps, throttle, and the per-item return fields (url/status/summary). It leaves the truncation behavior at the 30-cap and timeout semantics unspecified, which is a modest but real 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 every parameter already carries its own doc text and the baseline is 3. The description only repeats the max/interval defaults and adds the return-field shape; it adds no syntax or edge-case meaning (e.g. selector precedence vs article extraction) beyond 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?

Description states a specific verb and resource (搬运抓取多个 URL) and immediately differentiates itself from the single-URL sibling 'scrape' by framing the value as 'one call replaces N round trips'. An agent can tell this apart from scrape/crawl 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 gives clear context for when to use it (many URLs, replacing N round trips) and implies the alternative to looping 'scrape'. However it does not explicitly name 'scrape' or 'crawl' or state when NOT to use bulk mode (e.g. for a single URL or full-site traversal), so the routing guidance stays implicit.

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, so the description carries the full behavioral burden, and it leaves real questions open: whether calling it merely reads state or actively re-runs the test suites (potentially slow or costly), whether it is side-effect free, and whether any configuration is required. It does enumerate the return payload, which is its one behavioral contribution, but that is thin for an unannotated 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?

A single compact sentence that front-loads the core concept (engine health check) and then lists the payload items. No filler, no repetition of the tool name, and every clause carries 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 no output schema, the description must explain the return values, and it does so by naming all five result categories, which is the critical piece for a zero-parameter diagnostic. What is missing is the operational framing — whether this is a cheap read or a heavier self-test — so it falls just short of fully complete.

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 there is nothing for the description to disambiguate beyond what the empty schema already states. Baseline 4 applies; the description correctly avoids inventing parameter discussion.

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 frames the tool as an 'engine health check' (引擎体检) and enumerates exactly what comes back: version, passed tests, capability matrix, LLM availability, directory structure. That is a concrete, recognizable diagnostic purpose, and it clearly differs from the scraping-oriented siblings (scrape, crawl, screenshot). It stops short of explicitly naming when to prefer it over those siblings, but the intent is unambiguous.

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?

There is no guidance on when to call this tool: no mention of using it as a preflight/health-check step, no exclusions, no reference to alternatives among the sibling tools. An agent knows what it returns but not under what circumstances invoking it is appropriate or wasteful.

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: it does disclose the return shape and the recursive scope, which is useful. However, for a potentially heavy crawl it says nothing about rate limiting, timeouts, robots/politeness, or what happens when a page fails, and it never flags that same_domain defaults to false so the crawl may leave the domain.

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?

Two sentences, zero waste, with the core action and scope front-loaded before the use-case hint. Every clause earns its place.

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 usefully states the per-page return fields, and all seven parameters are covered by the schema. The remaining gap is behavioral: cost/duration and rate-limit expectations for a recursive crawler are unstated.

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% and the parameter descriptions are good (regex example '^/docs/', defaults for depth/browser/max_pages/same_domain), so the schema does the heavy lifting. The description adds nothing parameter-specific beyond the general notion of recursion, so the baseline 3 applies.

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: recursively crawl a whole site/subdirectory starting from an entry URL, and it also names the return shape (title + body + links per page). The word '递归' plus '整站/子目录' implicitly separates it from the single-page scrape sibling, but no sibling is named explicitly.

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 positive use cases, which is more than nothing. But it never says when NOT to use it, nor points to alternatives such as scrape for a single page or bulk_scrape for a known URL list, so the agent must infer the boundary from sibling names.

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 burden and does well: it discloses that sanitization runs by default stripping hidden elements, comments, and zero-width characters (prompt-injection vectors), and that main_only narrows to the main content container. It does not cover behavior on malformed HTML or that the operation is a side-effect-free pure transform.

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?

Two dense sentences with the transformation stated first and defaults/options after; minimal waste. Slightly clause-heavy but every clause carries 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 one-required-parameter transform with no output schema and no annotations, it covers purpose, defaults, sanitization behavior, and output kinds. Missing only return-shape specifics and failure behavior, which are minor here.

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 all six parameters are already documented. The description mainly reinforces the sanitization/raw interaction and main_only intent that the schema already states, adding only marginal nuance beyond the structured fields.

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 concrete transformation: converting HTML source into clean Markdown/body text/tables, with the goal of token-efficient reading. The input being raw HTML rather than a URL implicitly distinguishes it from scrape/crawl siblings, though no sibling is named explicitly.

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 conditional guidance (main_only=true is better for article pages; raw only when truly needed) but never states when to pick this tool over scrape, crawl, or auto. Usage is implied by the input type rather than spelled out.

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, so the description must carry the full behavioral burden. It describes output formats and use cases, but omits important scraping behavior such as rate limits, authentication needs, anti-bot handling, failure modes, and when JS rendering is required.

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 description is compact and front-loaded with the core action and output formats, followed by concrete use cases. Every phrase contributes to helping the agent understand the tool without unnecessary length.

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?

Given seven parameters, no annotations, and no output schema, the description is adequate but thin. It lists possible return content types, but does not explain the response structure, errors, or when specific options like selector, proxy, or browser should be used.

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 the schema already documents all seven parameters. The description adds only a high-level output summary and does not provide additional syntax or semantics beyond the schema baseline.

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 states a specific verb and resource: scrape a single URL, returning clean text/Markdown/article/tables/links. This is clear, but it does not explicitly distinguish the tool from siblings such as crawl, bulk_scrape, or extract.

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 lists clear usage contexts: reading webpage content, extracting article text, finding tables, and collecting links. However, it gives no exclusions or explicit guidance on when to prefer crawl, bulk_scrape, screenshot, or extract instead.

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. It helpfully discloses that the page is browser-rendered, the image is saved to a file, the file path is returned, and the image is not returned inline, but it omits operational details such as overwrite behavior, permissions, timeouts, or other side effects of writing a file.

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 description is compact and front-loaded, first stating the action and output, then the intended use. Every clause adds useful information with no 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?

Given a fully described four-parameter schema and no output schema, the description covers the essential return behavior by stating that the file path is returned and the image is not inline. It is nearly complete for this tool, though it could say more about file handling or constraints.

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 the schema already explains url, path, full_page, and wait_selector in detail. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline of 3 applies.

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 states a specific verb and resource: screenshot a page via browser rendering, save it as an image file, and return the file path. This is clear enough to distinguish it from scraping or crawling siblings by its image-file output, although it does not explicitly name or contrast those 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?

It gives a clear usage context: manual verification of rendering results and troubleshooting. It does not specify when not to use it or explicitly compare it with alternatives such as scrape or crawl, so it stops short of full routing guidance.

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