List all available structured data extractors with their supported domains and fields. Use this to discover what sites ClawFetch can extract typed data from. Cost: $0.001.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the operation is a listing (implying read-only) and states the cost ($0.001). It also describes the content of the response (domains and fields). There are no side effects or additional behavioral traits that need disclosing for a simple list 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?
The description is two sentences: the first states the action and output, the second provides usage guidance and cost. Every sentence earns its place; there is no redundancy or fluff.
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 simplicity (zero parameters, no output schema), the description is adequate. It covers the purpose, usage context, cost, and nature of the returned data. However, it does not differentiate from sibling tools like check_domains, which could be a slight gap, but the use case is clear enough.
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 has zero parameters, which is correctly reflected in the schema. The description adds context about what the returned data contains (domains and fields), which is useful but not parameter-related. Since there are no parameters, the baseline 4 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 uses a specific verb ('list') and identifies the resource ('structured data extractors') and the scope ('all available'). It also clarifies the intended use case ('discover what sites ClawFetch can extract typed data from'), which distinguishes it from sibling tools like check_domains and suggest_domains.
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 explicitly states when to use the tool: 'Use this to discover what sites ClawFetch can extract typed data from.' This gives clear context. It does not explicitly mention alternatives or when not to use, but the purpose is unambiguous.
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.
Most tools have distinct purposes: fetch_url, render_page, and parse_document are clearly differentiated by content type (static HTML, JS-heavy, office documents). While fetch_url and render_page overlap in edge cases, descriptions sufficiently reduce ambiguity. check_domains and suggest_domains are related but distinct (availability vs suggestions).
Most tools follow a verb_noun pattern (fetch_url, extract_data, check_domains), but a few deviate: health_check (noun_verb reversed) and wallet_info (noun_noun). The inconsistency is noticeable but not chaotic; all use snake_case consistently.
With 10 tools spanning web fetching, extraction, document parsing, research, and domain services, the count is appropriate and each tool serves a clear function. The set is slightly broad but remains within a reasonable scope.
The server covers the main workflow: acquiring web content (fetch/render/parse), extracting structured data (extract_data/list_extractors), researching topics, and domain checking/suggestions. Minor gaps exist (e.g., no OCR for scanned PDFs, no domain purchasing), but the core features are well-rounded.
