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

No annotations are provided, so the description carries the full burden. It discloses the asynchronous behavior, the return of a job id, and the need to poll with batch_status. It also explains that summary mode returns metadata only. However, it does not mention error handling, rate limits, or implications of failure. Core behavior is communicated but not exhaustively.

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 with zero fluff. The first sentence states the action and async pattern; the second adds a practical tip about summary mode. It is front-loaded and every word contributes, though it could optionally mention the polling flow earlier.

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 no annotations and no output schema, the description covers the essential workflow: submit batch → poll with batch_status. It explains the summary mode and its purpose. It does not elaborate on error scenarios or limits, but the schema already caps URLs at 5000. The description is sufficient for an agent to invoke the tool correctly for the typical batch-scraping use case.

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 baseline is 3. The description adds meaningful semantic value for the 'mode' parameter by explaining that summary mode carries metadata only (title, description, canonical, contentLength) and is intended for audits. Other parameters are left to the schema, but the mode enhancement justifies a score above 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 clear verb and resource: 'Scrape many URLs asynchronously with shared options.' It distinguishes itself from single-URL scraping by emphasizing the batch and async nature, and the mention of summary mode for audits differentiates it from other bulk tools like search_bulk. This is a precise and scoped purpose.

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 gives an explicit use case: 'For SEO/status audits over many pages set mode summary' and instructs to poll with batch_status. While it does not explicitly name alternatives or state when not to use it, the context of 'many URLs' and the async pattern clearly imply it is for bulk operations. The guidance is clear but could be stronger with explicit exclusions.

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 behavioral disclosure burden. It usefully reveals that polling is incremental and that page content is omitted by default unless include_content is set. It does not mention terminal states or result expiration, but the core behavior is disclosed.

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?

Three tightly written sentences. The main purpose is front-loaded, followed by the essential polling mechanics and then the content flag tradeoff. Every sentence earns its place 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 polling tool with three parameters and no output schema, the description explains how to poll, how to resume incrementally, and how to request full content. It could say more about completion semantics or response shape, but the critical usage information is present.

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 baseline is 3. The description reinforces the semantics of since and include_content, but these meanings are already present in the schema. It adds incremental contextual framing rather than wholly new parameter information.

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 verb and resource: 'Poll a batch job for progress and per-URL results.' This distinguishes it from sibling status tools like crawl_status or collector_run_status by tying it specifically to batch jobs.

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 gives explicit polling workflow guidance: polls are incremental and the previous response's nextCursor should be passed as since. It does not explicitly mention alternatives or when not to use this tool, so it stops 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 of behavioral disclosure. It does well by specifying the status values (queued|running|done|failed), result count, cost, partial flag, and result rows. It also documents the CSV format option. It does not mention polling behavior or error conditions, but the core behavioral surface is 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?

Two sentences with no filler. The primary action and return fields are front-loaded, and the usage prerequisite and format override are clearly stated. 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?

Given no output schema and no annotations, the description adequately enumerates return values and the prerequisite async call. It lacks only minor guidance on polling intervals or how to handle 'queued'/'running' states, but for a status-check tool this is sufficient. Could be a 5 if it included a brief note on polling, but the current coverage is strong.

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 baseline is 3. The description reinforces what the schema already says for run_id ('returned by run_collector') and format ('csv' returns rows as CSV text). It adds no genuinely new parameter-level meaning beyond the schema, so a 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 uses a specific verb ('Fetch'), identifies the exact resource ('a Collector run by run_id'), and enumerates the returned fields (status, result count, cost, partial flag, result rows). It clearly distinguishes itself from run_collector by explicitly positioning itself as the follow-up to an async 202 response.

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 gives clear contextual guidance: 'Use after run_collector returned 202/async.' This tells the agent when to invoke the tool. However, it does not explicitly mention when not to use it or name alternative status tools (e.g., dataset_status), which would elevate it to 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, the description must shoulder the burden of behavioral disclosure. It discloses that the operation is asynchronous, uses BFS, converts to Markdown, and returns a job id, which signals non-blocking behavior and a side effect (creating a job). However, it does not mention resource consumption, rate limits, whether it respects robots.txt, or if any setup (e.g., proxies) is required. This is adequate but not rich; a 3 is appropriate.

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, two sentences, and every clause contributes. It front-loads the core action ('Start an asynchronous BFS crawl'), specifies output format (Markdown), and immediately guides the agent to the next step (poll with crawl_status). There is no fluff, repetition, or unnecessary detail—exemplary conciseness.

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 7 parameters and no output schema, the description provides the essential guidance: what it does, how it returns results (job id), and how to follow up (crawl_status). It does not explain preconditions like proxy configuration (though the 'country' parameter implies proxy usage) or clarify how parameters affect the crawl, but these are mostly derivable from the schema. The missing nuance about setup and parameter interactions keeps it from a 5, but it is sufficiently complete for safe 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 description coverage is 100% and every parameter already has a description (e.g., 'Max link depth (default 3)', 'Max pages (default 50)'). The tool description adds no additional meaning about any parameter; it only references the 'BFS' mechanism, which is not tied to a specific parameter. Per the baseline rule for high coverage, a 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 ('Start'), a resource ('a site'), and a method ('BFS crawl'), plus the output ('converting each page to Markdown') and the return value ('Returns a job id'). It clearly distinguishes itself from sibling tools like 'scrape' or 'search' by emphasizing the asynchronous multi-page traversal and the need to poll with 'crawl_status'.

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 gives clear context: this is asynchronous, you get a job id, and you must poll with crawl_status. It implies the use case of crawling an entire site, but does not explicitly name alternatives or state when NOT to use this tool (e.g., for single-page scraping, use 'scrape'). The flow is clear, but exclusions are absent; a 4 reflects the lack of explicit alternative differentiation while providing solid usage direction.

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 behavioral burden. It discloses key behaviors: incremental pagination via `since`, default metadata-only response, and the large size of full content ('hundreds of KB'). However, it doesn't mention potential rate limits, error responses, or job completion states, which would be useful for a polling 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 compact at three sentences, front-loading the core purpose and then providing actionable polling and content guidance. Every sentence adds value without redundancy, making it easy for an agent to quickly grasp the tool's behavior.

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 polling tool with no output schema, the description covers essential usage patterns: incremental cursor passing, content size implications, and default behavior. It doesn't explain response fields beyond `nextCursor` or job lifecycle events (e.g., completion, errors), but it provides enough context for correct invocation. There is a small gap in describing what happens when the crawl finishes.

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 baseline is 3. The description reinforces the `since` parameter's role in incremental polls and the `include_content` default, but these are already well documented in the schema. The only added value is the size warning, which is minor; the schema already carries the semantic weight.

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 specific verb 'Poll' and the resource 'a crawl job', explaining it tracks progress and pages crawled. It distinguishes itself from sibling status tools like batch_status and collector_run_status by explicitly targeting crawl jobs. The purpose is unambiguous and directly actionable.

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 gives explicit usage guidance for incremental polling: 'pass the previous response's nextCursor as since' and for content handling: 'set include_content true only when you actually need the text'. It implies this is the correct tool for crawl job status, differentiating from siblings via the focus on crawl jobs, though it doesn't explicitly name alternatives or exclusion conditions.

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 present, so the description carries the full burden—and it delivers: it discloses asynchronous execution (job id + polling), output formats, billing per found record, premium field surcharges, and a hard cost cap with refund. This is strong behavioral disclosure for a complex, potentially expensive 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?

Two dense sentences are front-loaded with the core purpose, followed by the async contract and billing rules. No filler or repetition of schema content; 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?

For a complex 6-parameter tool with no annotations and no output schema, the description explains the pipeline, the job-id/polling flow, output formats, and the full billing and cost-cap behavior. An agent has enough context to invoke it correctly and set user expectations.

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 83%, so the schema already documents most parameters (prompt, limits, columns, sources, country, webhook). The description adds meaning mainly to limits.max_cost_usd by explaining the budget cap and refund behavior, but does not materially enrich the other parameters.

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 ('Build') and resource ('structured dataset'), and explains the full pipeline from prompt to validated rows in CSV/JSON. It also distinguishes itself by naming the polling endpoint (dataset_status), which separates it from direct scrape/crawl 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?

Clearly implies the intended use case: converting a plain-language request into a structured, validated dataset via multi-engine search and scraping. It does not explicitly name alternatives or when-not-to-use, but the scope is specific enough for an agent to select it over raw scrape/crawl tools.

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 responsibility for behavioral disclosure. It discloses that polls are incremental, that summary mode omits rows, and that completed jobs return signed download URLs. This covers key state changes and output behavior. It stops short of describing failure modes or rate limits, but the disclosed behaviors are accurate and non-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 two sentences, with the core purpose stated in the first phrase. Every clause adds critical information: incremental polling, the `since` mapping, summary mode, and completion behavior. There is no redundancy or filler, and the structure front-loads the most important context.

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 polling tool with 3 parameters and no output schema, the description covers all necessary usage aspects: how to poll incrementally, when to use summary mode, and what happens on completion. It does not describe the full response shape, but given the absence of an output schema, the mention of download URLs provides sufficient closure. An agent can confidently call this tool after create_dataset.

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 baseline is 3. The description adds value by explaining the `since` parameter's role as a cursor from the previous poll's `nextCursor`, and how `mode` affects output (omitting rows). These insights go beyond the schema's terse 'Row cursor from previous poll' and 'summary: progress + steps only', making the parameters more semantically meaningful.

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 opens with a specific verb+resource: 'Poll a dataset job for progress, the collection trace (steps) and the rows so far.' This clearly distinguishes it from sibling status tools like search_bulk_status, crawl_status, or batch_status by explicitly naming the dataset job context. The addition of incremental polling semantics and summary mode further pinpoints its unique role.

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 explains how to use the tool incrementally ('pass the previous response's nextCursor as since') and offers a lighter mode ('mode summary'). While it doesn't explicitly name alternatives or exclusion criteria, the context of dataset jobs and the polling pattern make the usage clear. It could benefit from an explicit note like 'use after create_dataset', but the information is present and actionable.

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 shoulders the full burden. It discloses the one-time LLM use, the deterministic and cost-free nature of subsequent scrapes, and the fact that selectors are verified against the page with report/coverage. It stops short of mentioning rate limits or auth, but for this read-only parser generation the core behaviors 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?

Three sentences, no fluff. The purpose is front-loaded, followed by usage guidance and a note on verification. Every sentence contributes value and none repeat 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?

Covers the primary use pattern, the alternative, and the reliability output (report/coverage). It gives an agent enough to decide when to call and what to expect, even without an output schema. Minor gaps like conflict resolution between url and html are left to the schema descriptions, which already exist.

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% for all six parameters, so the schema already documents semantics. The description adds workflow context (pass parser as extract) but does not elaborate on individual parameters beyond what the schema provides. 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+resource: 'Look at a page ONCE with an LLM and get back CSS selectors that extract the fields you asked for.' It also clearly differentiates from ai_prompt by noting it replaces AI on repeated scrapes, making the tool's niche unmistakable.

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 tells when to use it: 'Use this instead of ai_prompt whenever you will scrape more than a couple of pages of the same shape.' This names the alternative and the condition that selects it, leaving no ambiguity.

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 burden. It discloses that credentials are included, output is ready-to-use, and supports multiple protocols/formats. It mentions 'active proxy services' implying authorization is required, but does not detail error cases or quota usage. For a generation tool with no destructive behavior, this is adequate but could mention potential side effects like consuming service quota.

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?

Three sentences, front-loaded with purpose and usage hints. No redundancy, and each sentence adds value. The structure is efficient and scannable for an agent.

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 15-parameter tool with no output schema, the description covers key aspects: support types, targeting, rotation, protocols, formats, and prerequisites. It references companion tools for required data and gives an example (curl -x). While it doesn't enumerate all parameter interactions, the schema compensates with detailed descriptions. The description is comprehensive enough for an agent to correctly invoke the tool.

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%, with each parameter having a description. The description adds high-level context (e.g., 'geo targeting', 'rotating or sticky sessions') that aligns with parameters but does not provide additional per-parameter semantics. The only extra value is referencing list_proxies for orderId, which is helpful but not sufficient to raise above 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?

Clear verb+resource: 'Generate ready-to-use proxy endpoint strings' with explicit types (residential, mobile, datacenter, ISP, IPv6) and features (geo targeting, rotation, protocols, formats). It distinguishes from siblings like list_proxies and proxy_locations by specifying that it generates strings rather than lists or location data.

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 instructs prerequisites: 'Use list_proxies first to get the orderId, and proxy_locations for valid targeting codes.' This gives actionable redirects to sibling tools and clarifies when this tool is appropriate, leaving no ambiguity about initial setup.

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, and it delivers: it discloses the refetch of the source page, the conditional adoption rule (only if new selectors extract more), the no-op outcome, and — notably — the billing implication ('not billed' when no improvement). This is rich, safety-relevant context that an agent needs before invoking a mutation-like repair.

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 well-structured sentence with an em-dash clarifier that carries zero waste. The primary action is front-loaded, followed by the conditional caveat and billing note, each earning its place. No redundant modifiers or 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 compact tool (2 params, 1 required, no output schema, no nested objects), the description covers the operation, the conditional adoption behavior, and the billing consequence — everything essential to call it safely. The only minor gap is the unspecified return value, but given the tool's simple nature and absent output schema, this is not a critical omission.

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 both parameters (preset_id and force, including force's cooldown-bypass purpose). The description adds the operational meaning of 'heal' but does not elaborate on parameter formats or semantics beyond what the schema states. Baseline 3 applies since the schema does the heavy lifting.

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 opens with a specific verb+resource ('Regenerate a preset's selectors now') and immediately grounds it in context ('the manual trigger for the automatic repair'). This clearly distinguishes the heal operation from sibling tools like save_parser_preset or generate_parser by framing it as a repair trigger rather than a creation or edit.

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 explains the tool's role as the manual trigger for an automatic repair process, giving clear context for when an agent would invoke it. It also documents the edge case behavior (nothing better found → untouched). However, it does not explicitly name sibling alternatives or state when-not-to-use conditions, leaving some inference to the agent.

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 of disclosure. It states return fields, billing model (pay-per-success), and gives examples. It doesn't explicitly say it's read-only, but that's implied by the list operation. It covers relevant behavioral context like pricing and health status.

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 long due to the extensive list of examples, but the information is useful for an agent to know what collectors exist. The main purpose is front-loaded, and every sentence adds value (definition, examples, return fields, billing). It is structured and not tautological.

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 list tool with one optional parameter and no output schema, the description is sufficiently complete. It explains what collectors are, what fields are returned, and pricing. It doesn't specify pagination, but that is unlikely needed for a catalog listing.

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 input schema has one optional parameter 'category' with a description, achieving 100% schema coverage. The tool description adds no additional parameter information beyond what the schema provides, so 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 clearly states the tool lists ready-made Collectors, defines them, and provides a comprehensive list of examples. It distinguishes itself from sibling tools like list_parser_presets by specifying the resource type and the return fields.

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 implies usage: to discover available Collectors and their details. It provides context on what Collectors are and how they differ from URL-based scrapers. It doesn't explicitly mention alternatives or when not to use it, 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.

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

With no annotations, the description bears full responsibility. It conveys that the tool reads and returns stored presets, implying a non-destructive operation, but does not explicitly state read-only behavior, pagination, or ordering. Since this is a simple list, the omission is minor but leaves some behavior to inference.

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 a single, concise sentence that front-loads the action and resource, then enriches with the key attributes. No fluff or repetition; every word 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 parameterless list operation, the description is fairly complete, covering the resource and the nature of the output. It lacks explicit mention of return format (e.g., array) or pagination, but given the simplicity and absence of an output schema, it is sufficient for an agent to understand and invoke 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?

The tool has zero parameters, so the baseline is 4. The description adds value by detailing what information is included in the listing (version, health stats, changelog), exceeding the empty schema. This provides meaningful context for the agent about expected output.

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 verb 'List' and the resource 'your stored parser presets', and further specifies the included attributes (version, health stats, changelog). This effectively differentiates it from sibling tools like generate_parser or parser_preset_stats without ambiguity.

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?

While the description does not explicitly name alternative tools or conditions for non-use, the purpose is self-evident for a simple list operation, and the resource target is unambiguous. It clearly implies use when you need to view existing presets, which is adequate for this straightforward tool.

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 must carry the behavioral burden. It conveys a read-like operation via 'list' but does not explicitly state read-only or non-destructive behavior, nor does it disclose pagination or rate limiting. For a listing tool, the lack of explicit safety disclosure is a manageable gap 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 description is two sentences: the first packs the full scope and result fields, the second gives usage guidance. It is tight with no fluff, though the density might be slightly overwhelming; still, each element 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?

Even without an output schema, the description lists the returned fields (plan type, bandwidth, expiry, whitelisted IPs, orderId) and covers the plan types. It also mentions pagination-related parameters (limit, offset) via the schema, and the 'every type' phrase sets expectations. The description is reasonably complete for a list tool, missing only explicit notes on pagination behavior.

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% and each parameter is described in the schema. The description adds minimal new parameter meaning—it only mentions the orderId as an output, not a parameter. Thus the description provides no additional semantic value beyond the schema, warranting the baseline score 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 lists all proxy services with specific details and explicitly mentions the orderId for generate_proxies, distinguishing it from the create-oriented sibling. It names the exact resource (proxy services) and the verb (list), making the purpose unmistakable.

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 instructs to 'Call this first to see which proxy plans are available,' providing a clear use case and ordering relative to generate_proxies. It does not list formal exclusions, but the 'first' directive gives enough context to route the agent correctly.

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 does this well by explaining the return shape (limited URLs, site-wide total, per-section summary), the filtering behavior, and the grouping alternative. It does not cover failure modes or edge cases, but the core behavior is 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 description is dense but efficient, with the main purpose front-loaded and parameter behavior woven into contextual prose. It could be slightly trimmed, but every sentence carries useful information and there is 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?

There is no output schema, so the description must convey the return shape, and it does: limit, total, summary, and the group_by path-tree alternative. It also contextualizes search as the primary filtering path. Minor omissions like includeSubdomains behavior are already covered by the schema, so the overall definition is complete 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: it explains the default limit, that total/summary always cover the whole site, that search is the primary narrowing mechanism, and that group_by produces a path tree with counts. This is genuine added value.

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 opens with a specific verb and resource: 'Discover a site's URLs fast' and names concrete discovery sources (robots.txt sitemaps, /sitemap.xml, homepage links). It also distinguishes itself from a full crawl, making it easy to differentiate from the sibling crawl tool.

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 states it is for fast URL discovery 'without a full crawl', giving context for when to use it versus crawling. It also explains how to narrow results with search and group_by. It doesn't explicitly name all sibling alternatives or exclusion conditions, but the 'without a full crawl' contrast provides enough guidance.

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 of disclosing behavior. It does explain what 'decayed' means and what statistics are computed, but it never states that the operation is read-only or whether it has side effects. The tool is clearly a stats/status query, so the omission is moderate rather than severe.

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 sentence that front-loads the core purpose ('How well a stored parser is still working') and then enumerates the exact output components. Every word earns its place; no redundant or vague 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 one-parameter tool with no output schema, the description is nearly complete: it lists the three categories of results and explains the decayed flag. It could specify value formats (e.g., percentages or ratios) or error behavior for unknown presets, but nothing critical is missing for invoking the tool.

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%, and the schema already explains that preset_id comes from save_parser_preset. The description adds no parameter-level detail beyond referring to a 'stored parser', so the baseline score 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 clearly identifies the resource (a stored parser/preset) and the specific data it reports: success rate per field, mean coverage, and a decayed flag. It lacks an explicit verb like 'retrieves' or 'returns', but the meaning is unambiguous and distinct from siblings like dataset_status or list_proxies.

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 phrase 'over the recent runs' gives clear context for when to use this tool: after a parser has been exercised, to assess whether it still works. It does not mention alternatives or exclusions, but the sibling tools are sufficiently different that no routing guidance is strictly needed.

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 behavioral disclosure burden. It mentions the tree can be large, which is a useful behavioral trait, and implies a read-only discovery operation. However, it does not explicitly state that there are no side effects, what happens on invalid input, or any authentication requirements. For a read-only lookup, this is acceptable 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 description is two sentences long and effectively front-loads the core purpose. Every clause adds value: the list of value types, the explicit link to generate_proxies, the guidance on tree usage, and the size warning. There is no fluff or redundant restatement of the tool name.

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 simple lookup nature and fully described schema, the description is quite complete. It explains what results to expect (geo-targeting values), the structure of the tree, and a practical caveat about its size. There is no output schema, but the description implies the content of the response. The only minor gap is not specifying the exact output format (e.g., whether it returns a list of objects or a hierarchy), but this is reasonable for a discovery tool.

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 baseline is 3. The description adds meaningful value beyond the schema by explaining when to use 'tree' (for specific plan types and ISP codes) and warning about its size. It also clarifies the dependency on planType and the optional filters for states/cities, enriching the parameter semantics without redundancy.

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 purpose: discovering valid geo-targeting values for a proxy plan type. It enumerates the specific value types (countries, states, cities, ASNs, tree) and explicitly links it to the prerequisite step before calling generate_proxies. This unambiguously distinguishes it from siblings like list_proxies or generate_proxies.

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 usage context by stating to use this before generate_proxies and gives precise guidance on when to use the 'tree' level (for Residential Premium / Mobile V2 slugs, ISP codes, and the static datacenter gateway list). It does not explicitly mention alternatives or when not to use it, but the intent is clear. The warning about tree size also helps decision-making.

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 must carry the full burden, and it does: it discloses return behavior (short runs return rows, long runs return 202 with run_id/statusUrl), billing semantics (per delivered row, never for failures), and the async flag's effect. This gives the agent a solid mental model of the tool's runtime behavior and side effects.

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?

Three sentences, zero fluff. It front-loads the purpose, then packs behavior, billing, and async guidance efficiently. Every sentence earns its place with actionable 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?

Despite no output schema, the description provides essential return information (inline rows vs 202 with run_id/statusUrl) and points to collector_run_status for polling. It also references list_collectors for input schema details, completing the contextual loop. It does not mention error scenarios or parameter validation, but the core information needed to call the tool correctly is present.

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 baseline is 3, but the description explicitly clarifies how to use each parameter: slug from list_collectors, input matching the collector's inputSchema (with an example), and async to force background execution. This adds real semantic value beyond the schema's field descriptions, making it a 4.

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 ('Run') with a clear resource ('a Collector by slug') and the key input type ('semantic input'). It distinguishes from siblings like list_collectors (listing vs executing) and collector_run_status (polling vs initiating). The description leaves no ambiguity about what the tool does.

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 points to list_collectors for inputSchema preparation and to collector_run_status for long-run polling, giving the agent the correct workflow. It also explains when to use the async flag ('force background execution'), which provides clear usage context. No alternative tool is mentioned as a replacement, but the reference to these siblings establishes when this tool is appropriate.

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 discloses that every run is scored per field and that the preset regenerates itself on decay, bumping a version. It also transparently notes that without a source_url it can never self-heal. This adds significant behavioral context beyond the schema. It does not mention permissions or side effects like name conflicts, but the core behavior is well conveyed.

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?

Three sentences with no fluff. The first sentence states the primary purpose, the second explains reuse, scoring, and self-healing, and the third gives a best-practice recommendation. Information is front-loaded and 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 6 parameters, nested objects, and no output schema, the description covers the primary use case, the self-healing behavior, and the critical dependency on source_url. It doesn't explain return values or edge cases like name conflicts, but the essential information for correct selection and invocation is present. Given the complexity, it is reasonably complete, though more detail about the return value and overwrite behavior could push it to 5.

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 baseline is 3. The description adds little beyond the schema; it reiterates the self-healing requirement of source_url but doesn't elaborate on parameters like `fields` or `auto_heal`. It mentions `preset_id` but that is not a parameter of this tool. No additional parameter meaning is provided, so a score 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 clearly states a specific verb ('Store'), a specific resource ('a generated parser'), and its purpose ('so it can be reused by id'). It also distinguishes itself from siblings by referencing scrape's `preset_id` and self-healing behavior, making it distinct from generate_parser and list_parser_presets.

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 explains the usage context: save a parser for later reuse via scrape's `preset_id`, and advises to provide a `source_url` for self-healing. It doesn't explicitly state when not to use it or alternative tools, but the context of generating a parser first and then saving is implied. The instruction 'Give it a source_url whenever you can' is a clear guideline. No explicit exclusions or alternatives are named, but the purpose is direct.

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 present, the description carries the full disclosure burden and exceeds it. It reveals the residential proxy usage, Chrome TLS fingerprint default, conditional headless-browser escalation, default Markdown behavior, and content_mode 'smart' details. This gives an agent an accurate mental model of how the tool will actually behave, including escalation and output preprocessing.

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 dense but deliberately structured: core purpose first, then network/browser behavior, then optional extraction and output defaults. It avoids filler, though one or two long sentences pack a lot of clauses. For a tool with this many capabilities, it is appropriately sized and front-loaded.

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, together with the fully documented schema, covers the main behaviors, output formats, extraction options, and important edge-case choices like engine escalation and raw HTML fallback. It does not define a high-level response envelope or error semantics, but the parameter-level payload descriptions compensate well. Given the tool's complexity, this is a high-quality, complete definition.

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 schema itself contains rich explanations for all 31 parameters. The main description adds strategic framing for a few features (e.g., extraction via CSS selectors or natural language) but does not need to re-document parameters. This is the appropriate baseline-3 case where the schema carries the heavy lifting.

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 opens with a precise verb and resource: 'Scrape a single web page through a residential proxy.' It clearly distinguishes this tool from the crawl and search siblings by emphasizing single-page scraping. It also enumerates the major processing modes (Markdown, HTML, text, structured extraction, AI extraction) without ambiguity.

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 establishes clear context: it is for one page, with optional extraction modes. It names helpful routing details such as 'use this to DISCOVER the API, then fetch_resource to return it directly' and distinguishes raw no-JS/SEO fallback via format 'html'. It does not explicitly state when to prefer crawl or search_and_read instead, but the single-page framing and sibling names make the intended usage reasonably inferable.

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 full responsibility for behavioral disclosure. It reveals that searches run through a residential proxy, that Bing and Google operate over HTTP (not a browser), that Bing may return Copilot AI answers and citations, and that Google parses rich blocks directly from the HTTP response. This goes beyond a simple 'search' verb and informs the agent about underlying mechanics, though it does not cover rate limits, authentication, or pagination behavior.

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, front-loaded with the main purpose and engine support. It is efficient with no wasted words, appropriate for a tool whose parameters are exhaustively documented in the schema. It does not enumerate parameters or repeat 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?

Despite the schema covering parameters, the description fails to convey the full scope of the tool. It mentions Bing's verticals and Google's rich blocks but does not hint at the many Google-specific search types (hotels, flights, reviews, trends, etc.) or the fact that the tool supports non-web verticals. With 38 parameters and no output schema, the description should provide a broader overview, but it leaves the agent to discover capabilities solely from the schema.

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% with detailed parameter descriptions, so the baseline is 3. The description itself adds no additional parameter meaning beyond what the schema already provides. It does not compensate for any gaps because none exist; the schema already exhaustively documents the 38 parameters.

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 runs structured searches across Google, Bing, and DuckDuckGo through a residential proxy, and highlights Bing's verticals and Google's rich-block parsing. This is specific, action-oriented, and distinguishes it from siblings like `search_bulk` (bulk queries) and `search_and_read` (reading content). It is not a tautology.

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 no guidance on when to use this tool versus alternatives such as `search_bulk`. It does not mention any conditions, exclusions, or comparative context. While the parameter descriptions in the schema reference `search_bulk`, the description itself is silent, leaving the agent to infer usage from the schema alone.

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 discloses the core behavior (live search, fetching top pages, returning Markdown and a context string) and adds context about citation-ready sources and token bounding. It doesn't mention any side effects or rate limits, but for a read-only search tool this is reasonable. It also doesn't describe the fetch_content=false variant, leaving that to the schema.

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 filler. The first sentence front-loads the action and output, the second gives concise routing guidance. Every word 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 tool has 7 parameters, no output schema, and no annotations. The description covers the operational flow and output format (numbered sources + context string) enough for an agent to call it correctly. It doesn't describe all parameter options, but the schema does. Minor gaps like the fetch_content=false behavior are left uncovered, but the core contract is clear.

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% (every parameter has a description), so the baseline is 3. The description adds minimal parameter-specific meaning: 'top organic pages' maps to top_n, 'token-bounded' hints at max_tokens, but it doesn't go beyond the schema. No parameter details are missing.

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 opens with a specific multi-step verb phrase: 'Search the live web, fetch the top organic pages as clean Markdown, and return citation-ready numbered sources plus one token-bounded `context` string.' This clearly distinguishes the tool from the sibling `search` by naming the output format and the intended research/answering use case.

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 this tool ('when the goal is answering/researching') and when to use the alternative ('use `search` when raw SERP structure or a specialized vertical is needed'), naming the sibling and the discriminating condition.

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. It discloses key behaviors: asynchronous execution, deduplication, retention of page-one enrichments, the effect of setting render:true, and billing logic with refunds. It does not mention rate limits or authentication, but it covers the operational traits an agent needs to know before invoking, so it is strong.

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?

Three sentences with zero filler. The main function is front-loaded, then the enrichments and billing are stated compactly. Every sentence earns its place; 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 complexity (16 parameters, async execution, billing), the description is reasonably complete but omits critical operational details. It does not explain how to retrieve the results (e.g., job ID or status endpoint), nor the output format. The sibling 'search_bulk_status' suggests there is a status mechanism, but the description does not mention it, leaving an agent to infer the interaction pattern.

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 baseline is 3. The description adds meaning by linking 'render:true' to the capture of Google JS blocks (a functional hint), and clarifies billing per page which affects usage. It does not elaborate on other parameters like wait_for or google_params, but the added hints are beneficial and go beyond simple schema descriptions.

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 ('Paginate') and resource ('ONE search query'), and explicitly mentions the async, deduplicated, and merged nature of organic results. It clearly distinguishes itself from a single-page search tool by emphasizing pagination and consolidation, making it easy for an agent to differentiate from siblings like 'search'.

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 implies usage for paginating a search across multiple pages, but it does not explicitly compare with alternatives like 'search' or 'search_and_read'. There is no 'when to use' versus 'when not to use' guidance, nor mention of the status-tracking sibling tool. The context is clear that it is for bulk retrieval, but lacks explicit routing.

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 of behavioral disclosure. It reveals a key behavioral trait: incremental polling where only newer results are returned via the since parameter. This is non-obvious and valuable. It does not cover job completion detection or error handling, but the core polling behavior is well explained.

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 exactly two sentences: the first states the purpose, the second explains the incremental polling mechanism. Every sentence earns its place, and the core purpose is front-loaded.

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 adequately explains the tool's main purpose and usage pattern, and even covers a subtle point (incremental results). Since there is no output schema, it would be helpful to mention what the response contains, but the phrase 'progress and merged organic results' gives a reasonable summary. Overall it's complete enough for an agent to invoke 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?

The input schema already describes both parameters (jobId and since) with 100% coverage, so the description doesn't need to add much. It does reinforce that jobId comes from search_bulk and since reuses nextCursor, but essentially restates what the schema already provides. Baseline 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 clearly states the tool's purpose: polling a bulk search job for progress and merged organic results. It uses a specific verb ('Poll') and resource ('bulk search job'), which distinguishes it from related tools like search_bulk that initiate jobs. The incremental polling behavior further clarifies its role.

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 clear context that this tool is used after a bulk search job is created, and explains the incremental polling pattern (passing nextCursor as since). However, it does not explicitly mention alternatives or when not to use this tool compared to other status polling siblings.

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 full behavioral disclosure. It explains the dual-fetch behavior, what each view contains, and the diff. It also doesn't mention side effects, but as an audit it's implicitly read-only. The no_render parameter's effect is also disclosed. Minor omission: no mention of rate limits or auth, but that's not critical for a read 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?

Two sentences, no fluff. The core purpose is front-loaded, and details are packed efficiently. Every clause earns its place, covering behavior, outputs, and usage guidance.

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 no output schema, the description lists the exact return fields (title, description, canonical, h1, word count, diff, meta). It explains the no-JS vs rendered distinction and the diff. It doesn't specify the response format (e.g., JSON structure) but enumerates enough for an agent to infer the shape. No critical missing information for calling 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 100% with descriptions for all three parameters. The description adds value by explaining how parameters interplay: it mentions the dual fetch and the diff, making the no_render parameter's role clearer in the audit context. It also clarifies which fields are returned, enriching understanding of 'url' and 'country' usage.

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 starts with 'Audit a URL's SEO in one call' and details exactly what it does: fetches twice (bot and rendered), returns both views, the diff, and bot-facing meta. It explicitly contrasts with manual scraping, clearly distinguishing it from the sibling 'scrape' tool.

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 final sentence, 'Use this instead of scraping manually when checking how a page indexes,' provides explicit guidance on when to choose this tool over alternatives. While it doesn't list other tools by name, it sets a clear decision rule.

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?

There are no annotations, so the description carries the full burden. It does disclose a key behavioral consequence: a whitelisted machine uses the proxies without username/password. However, it does not explain whether changes take effect immediately, whether adding an IP overwrites or appends, what the list action returns, or how removals affect active sessions.

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 efficient sentences: the first defines purpose and actions, the second gives usage context. Every clause earns its place, and the most important information is front-loaded.

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 plus the fully covered schema is enough to understand what the tool does and when to use it. However, the tool has 11 parameters that are action-dependent, and the description does not clarify which parameters apply to add vs remove vs list, nor does it describe the output of the list action beyond 'current entries'. This leaves meaningful gaps for correct invocation across all variants.

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 input schema provides descriptions for all 11 parameters, so the schema already carries the parameter-level documentation. The description adds no new parameter-specific meaning beyond the general auth context and the action names, which mirror the action enum. This is a solid baseline-3 case.

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 resource (IP-auth whitelisting on a proxy service) and explicitly enumerates the actions available (add, remove, list). It also scopes the feature to specific proxy types, which clearly distinguishes it from sibling tools like list_proxies or generate_proxies.

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 states when this tool is required ('required for the Mobile V2 IP-auth proxy list') and when it is not needed ('Residential Premium/Private use user:pass auth and don't need this'). This gives the agent clear selection criteria and prevents unnecessary or incorrect calls.

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