结构化抽取网页要素（表格/链接/图片/标题大纲/元数据/自定义 CSS 选择器），返回 JSON。
与 scrape_url 的区别：不返回整页正文，只返回指定结构——表格转成 headers+rows
的 JSON 可直接计算；配自定义选择器可精准取价格/标题等字段。
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | 要抽取的网页 URL（http/https，仅限公开网页） | |
| targets | No | 抽取目标子集：metadata / headings / links / images / tables，默认 metadata+headings+links+tables | |
| selectors | No | 可选 CSS 选择器映射 {名称: 选择器}，每个选择器返回匹配元素的文本列表 |
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.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct role: site_map discovers URLs, scrape_url fetches a single page, crawl fetches multiple pages, and extract returns structured JSON. The overlap between scrape_url and crawl is clearly addressed in descriptions by single vs multi-page, so an agent can easily select the right tool.
The names are mostly intuitive, with two verbs (crawl, extract) and two noun phrases (scrape_url, site_map). The mix of verb and noun forms is a slight inconsistency, but all names are lowercase with underscores, so the pattern is still predictable.
With only 4 tools, each serves a distinct step in the web data workflow: discovery, single-page fetch, multi-page crawl, and structured extraction. This is an appropriate scope for the server's purpose, neither too sparse nor overwhelming.
The tool set covers the full pipeline from discovering URLs (site_map) to fetching content (scrape_url, crawl) to extracting structured data (extract). There are no obvious gaps for the server's stated purpose of web data collection and transformation.