stagenth · 网页数据

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

With no annotations, the description carries the full burden and discloses key behaviors: per-page billing (1 credit/page), pure crawling with no AI content, per-page SSRF checks, and non-interrupting failure handling. However, it omits details like rate limits, robots.txt handling, or exact output structure.

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 concise and front-loaded: two short paragraphs cover purpose, billing, security, and failure behavior without redundancy. Every sentence 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?

The description provides a solid overview of behavior, billing, and resilience, but lacks a stated output format (e.g., list of {url, markdown} objects), which is important given there is no output schema to explain return values.

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 schema covers 100% of parameters with descriptions. The tool description does not add parameter-specific semantics beyond what is already in the schema, so the baseline of 3 is appropriate.

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 action ('从入口 URL 广度优先抓取多页，每页转干净 Markdown') with a clear resource (entry URL and multiple pages). It distinguishes from sibling tools like scrape_url (single-page) and site_map (site structure) by emphasizing multi-page crawling with Markdown conversion.

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?

The description clearly implies use for multi-page crawling tasks, but it does not explicitly mention alternatives or when not to use this tool. The context is clear overall, but exclusions are absent.

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 provided, the description carries the full burden of behavioral disclosure. It explains that the tool transforms tables into headers+rows JSON and that custom selectors return text lists of matching elements, providing meaningful insight into the return behavior. It does not mention potential pitfalls like dynamic content or error handling, but the core behavior is transparent and not misleading.

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 concise and well-structured. It uses two sentences: the first lists the supported structured elements and return format, the second directly contrasts with scrape_url and provides a practical use case. Every word earns its place 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 the tool's moderate complexity (3 parameters, no output schema), the description is quite complete. It covers the main purpose, key distinctions, and expected behavior. It doesn't spell out the exact JSON structure for every target type, but the names of the targets are self-explanatory (metadata, headings, links, images, tables) and the examples provided give sufficient context for an AI agent to infer the output shape.

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 parameters are already documented. The description adds value beyond this by giving concrete examples (extracting prices/titles) and clarifying the transformation behavior for tables, which enriches understanding of how the 'targets' and 'selectors' parameters operate. This goes beyond a simple baseline of 3.

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 clearly states the tool's function: structured extraction of web page elements (tables, links, images, headings, metadata, custom CSS selectors) returning JSON. It explicitly differentiates from the sibling tool scrape_url by noting it returns only specified structures, not the full page content, which distinguishes it effectively.

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?

The description provides explicit guidance on when to use this tool: when you need structured data like tables convertible to headers+rows rather than the full page, and when you need precise field extraction via custom selectors. It names scrape_url as an alternative and explains the difference. However, it does not mention cases when the tool is not appropriate or when other siblings (crawl, site_map) should be used, so it falls short of a 5.

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 provided, the description carries the burden and discloses key behaviors: it only fetches and converts, does not generate content, and uses real browser rendering when render=true. It stops short of describing error handling or details for all parameters, but the essential traits are covered.

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 only two sentences, front-loaded with the core purpose, and includes a practical usage tip without any redundant or filler wording. Every sentence 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?

For a tool with 4 parameters and no output schema, the description covers the primary use case, constraints, and advanced rendering option. It does not mention the formats or only_main_content parameters, but the schema fills those gaps. A brief pointer to sibling tools would improve completeness, but it is already sufficiently informative.

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 schema fully documents each parameter. The description adds minimal extra semantics beyond repeating the render=true suggestion already present in the schema. It meets the baseline for well-documented schemas but does not go further.

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: '抓取一个公开网页，返回干净的 Markdown' (fetch a public webpage, return clean Markdown). It also clarifies the tool only fetches and converts, not generates, which differentiates it from siblings like 'extract' or 'crawl'.

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 provides clear context: only public webpages, prohibited intranet/reserved addresses, and advises using render=true for JS-heavy dynamic pages. However, it does not explicitly compare with sibling tools or state when not to use this tool in favor of alternatives.

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 full burden. It discloses key behaviors: prioritizing robots.txt/sitemap.xml and falling back to entry-page link discovery when no sitemap exists. It also hints at cost efficiency ('省 credit'). While it doesn't cover rate limits or error handling, the disclosed behavior is meaningful and non-generic.

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 concise sentences deliver the core purpose, method, fallback behavior, and integration guidance. Every sentence earns its place, with no filler or repetition of schema content.

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 the tool's moderate complexity, the description adequately covers how it discovers URLs and how to use it in conjunction with sibling tools. It lacks an explicit statement about return format, but that's not required given the absence of an output schema and the simplicity of the tool. Overall, it provides sufficient context for an agent 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?

Schema description coverage is 100%: both 'url' and 'max_urls' are already described in the schema. The description adds no extra parameter-level detail beyond what the schema provides, so it receives the baseline score for high coverage.

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 uses a specific verb+resource: '发现站点 URL 清单' (discover site URL list) and clearly states the method (robots.txt/sitemap.xml first, fallback to entry page links). It distinguishes itself from siblings like crawl and scrape_url by focusing on URL list discovery rather than full crawling or content extraction.

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?

The description explicitly advises using site_map before scrape_url or crawl to select target pages and save credits, providing clear when-to-use context. It doesn't mention when not to use it or alternatives beyond the stated sibling tools, but the cooperative workflow is well articulated.

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