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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds value beyond them by naming the concrete returned fields (email, credits, concurrency), which is important because no output schema exists to reveal the response shape.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences: the purpose and returned fields come first, the docs link trails. Every element earns its place and nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only status tool with full annotation coverage this is close to complete: the agent knows what it does, that it is safe, and what data comes back even without an output schema. Only minor behavioral notes (credits are consumed quota, error behavior when auth is missing) are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to disambiguate. Baseline of 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?

States a specific verb and resource ('Get your WebScraping.AI account status') and enumerates exactly what is returned: email, remaining credits, concurrency. This is unmistakably distinct from the scraping-oriented siblings (html, text, serp, data), so no schema opening is needed to disambiguate.

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?

Usage is implied by the tool's nature but never stated: there is no guidance such as 'call this before batch jobs to verify remaining credits' and no mention of when not to use it. With one obviously non-overlapping sibling set, the implied context is adequate but thin.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral detail beyond them: return shape, parse_status values, learning latency up to 45 seconds, 503 structure_processing retry behavior, 422 structure_unavailable handling, redirect behavior, and pricing/charging rules. This is unusually transparent for an agent deciding how to invoke and interpret the 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 front-loaded with the core action and return format, and most sentences convey necessary behavior around parsing, errors, and billing. It is dense and long in a single paragraph, but the detail is largely earned by the tool's complexity rather than being 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?

Given six parameters, no output schema, and an open-world read-only tool, the description is complete enough: it explains the response object, parse status semantics, latency/learning behavior, key error cases, and billing implications. The schema already documents the parameters, so the description fills the remaining behavioral gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters already have structured descriptions. The tool description adds little parameter-level meaning beyond saying the URL is sent as-is, which is already covered by the schema; the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get structured JSON for any public web page from its normal URL.' It explains exactly what the tool returns and distinguishes the fallback case by naming webscraping_ai_fields when structured data is unavailable.

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 usage context: it is for structured JSON from a normal public URL, and it explicitly redirects the agent to webscraping_ai_fields when a 422 structure_unavailable occurs. It does not broadly compare itself with the other siblings such as html, text, question, or selected, so it falls short of full when/when-not 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?

Annotations already cover read-only and open-world, so the description focuses on what they can't say: exact return shape, null for missing values, no nested objects/arrays, and that the LLM step adds cost on top of the scrape. That cost disclosure and the flat-value constraint are genuinely useful. Pagination/rate-limit details are absent, but for a single-page scrape they matter less.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences: purpose first, then return contract, then the negative constraint on nesting, then cost and docs. No filler, and the docs link is placed at the end where it belongs.

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?

No output schema exists, and the description fully specifies the return envelope and per-value type/null semantics, which is exactly what's needed. The 13 scrape-mechanics parameters (proxy, js, timeout) are left to their schema descriptions, which is appropriate given 100% coverage.

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, but the description adds meaning beyond the schema for the key `fields` parameter: values are always strings, never nested, so a list must be requested as one delimited string. That directly changes how an agent should phrase field instructions.

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 plus resource: scrape a page and have an LLM extract named values, restricted to the page's own content. The 'fields' framing differentiates it from siblings like webscraping_ai_question and webscraping_ai_text, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by 'extract named values' but there is no explicit when-to-use or when-not-to-use guidance, and no comparison against webscraping_ai_question or webscraping_ai_text. The 'using only the page's own content' clause narrows behavior but is not a routing 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?

Annotations already declare readOnly/openWorld/non-destructive, so safety needs no restating, but the description's parenthetical '(with JavaScript execution by default)' directly conflicts with the schema, where the `js` parameter defaults to false. That misstatement can cause an agent to assume rendering when it will not happen, and the description adds nothing about credits, proxy cost, or rate limits for a paid scraping call.

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 short sentences, capability front-loaded, docs link appended with no filler. It is tight, though the misleading default claim and the absence of any hint about the 13 optional parameters leave the sentence budget underused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 14 parameters, no output schema, and no annotations explaining cost or auth, the description is far too thin: it never says what the returned HTML looks like, whether errors surface as HTTP errors, how `format` changes the response shape, or that residential/stealth proxies cost extra. It also mismatches the schema on JS rendering, so an agent cannot call it correctly from the description alone.

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 alone earns a baseline 3, but the description does not merely stay silent — it asserts a JS default that contradicts the documented `js` default of false. For a 14-parameter tool the description adds no orienting detail (which params matter, cost implications of `proxy`, timeout ceiling), and its one parameter claim is misleading.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the full rendered HTML of a web page') and signals the JS-rendering aspect, which distinguishes it from the plain-text siblings in spirit. However, it never names webscraping_ai_text, webscraping_ai_selected, or webscraping_ai_fields, so the agent must infer the HTML-vs-extracted-content boundary from names alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the nine sibling scrapers, no when-not conditions, and no mention of prerequisites such as API key or credit consumption. The only routing aid is a docs URL, which an agent cannot reliably follow mid-task.

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?

Annotations already cover safety (readOnlyHint, destructiveHint=false) and open-world access, so the bar is lower, yet the description adds non-obvious operational facts: the LLM step is billed on top of the scrape cost, failed answers return an error whose body.error starts with 'Invalid page or question', and credits are refunded in that case. That is genuinely useful error-handling context an agent cannot get from the schema. It stops short of covering pagination/latency or how long the LLM step takes, so it is strong rather than complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with purpose, then failure/billing semantics, then sibling routing, then a docs URL. Every sentence carries distinct information and there is no restatement of the title or 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?

For a 13-parameter, annotation-backed tool with no output schema, the description supplies the return format (plain text), the failure shape (error with a specific body.error prefix), the billing model, and routing to alternatives. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 13 parameters including the required url and question are already documented in structured fields; the baseline is 3. The description reinforces the question parameter's intent ('using only the page's own content') but adds no syntax, format, or example for any parameter beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names a concrete verb chain (scrape a page, have an LLM answer a question about it) and constrains it to the page's own content, which is a real semantic distinction. It is immediately distinguishable from siblings like webscraping_ai_text or webscraping_ai_html, which are named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states both the fit ('suited to a single fact or short answer') and the alternatives with the condition that selects each: webscraping_ai_fields for several named values, webscraping_ai_text for reading/reasoning over the whole page. That is an explicit when/when-not/alternative mapping.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds only the 'first matching element' scoping behavior and otherwise says nothing about error handling, no-match results, or proxy cost implications (which live in the schema). Adequate but thin given the annotation headroom.

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 short sentences with the core behavior front-loaded and no redundant restatement of the title. The trailing docs URL is compact and arguably useful, though it substitutes for real in-description 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 14-parameter tool with no output schema, the description should at least clarify the return shape (HTML string of the matched element) and behavior when nothing matches; it states only 'Get the HTML'. The rich schema compensates for parameter completeness but not for output/edge-case 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 description coverage is 100% across all 14 parameters, including enums and defaults, so the schema carries parameter meaning fully. The description adds no parameter-level detail (e.g., how selector interacts with wait_for), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get the HTML of the first page element matching a CSS selector') with scope explicitly limited to the first match, which implicitly distinguishes it from sibling webscraping_ai_selected_multiple. It does not name the sibling outright, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus webscraping_ai_html (full page HTML), webscraping_ai_text, or webscraping_ai_selected_multiple. The only pointer is an external docs link, leaving the agent to infer selection criteria from the one-line purpose.

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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only the core extraction behavior and an API docs link; it does not disclose additional behavioral details such as return shape for multiple matches, handling of missing selectors, or proxy-related costs beyond what the schema already says.

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: one front-loaded statement of what the tool does and one documentation pointer. There is no redundant or low-value text.

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 schema fully documents all 13 parameters and annotations cover the read-only/open-world nature, so the description does not need to restate those. However, for a multi-selector extraction tool with no output schema, the description could say more about what the agent receives back or how multiple selector results are structured.

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 one of the 13 parameters is documented in the schema. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get the HTML of all page elements matching a list of CSS selectors.' This clearly distinguishes the tool from a full-page HTML fetch or a single-selector extraction, though it does not explicitly name the siblings it differs from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives such as webscraping_ai_selected or webscraping_ai_html. The phrase 'matching a list of CSS selectors' implies the multiple-selector use case, but the description does not state exclusions or conditions for selecting this 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?

Annotations already establish it as a read-only, open-world, non-destructive operation. The description adds substantive behavior beyond annotations: fixed-location consistency across repeats and pages, de-duplication in multi-page fetches, pricing per results page, and no charge for failed searches.

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?

Front-loads the tool's purpose and return structure, then covers pagination, location consistency, pricing, and workflow guidance. The density is justified by the tool's complexity and no sentence is clearly wasteful.

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?

No output schema exists, but the description explains the returned JSON sections well enough for an agent to understand results. It also covers key operational constraints such as page limits, location consistency, and charging for a 12-parameter 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 description coverage is 100%, so every parameter is already documented in detail. The description reinforces location consistency, page position behavior, and pricing, but mostly repeats or summarizes what the schema already says rather than adding new parameter-level meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: search Google and get parsed JSON results. It enumerates the returned sections (organic_results, related_searches, search_information, pagination), which makes it clearly distinguishable from sibling extraction tools.

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?

Explains its role in the workflow: use it to find pages, then read them with webscraping_ai_text or the other tools. It also notes when multi-page fetching is appropriate via pages and describes charging behavior for failed searches.

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 output schema, the description carries the full burden and does so: result count cap, ordering ('most populous first'), per-item field list with meaning of each, and the cost signal ('Free'). Annotations already cover read-only safety, and the description adds substantive context beyond them.

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 dense sentence-package that front-loads purpose, then returns, then matching semantics, then cost and docs link. Every clause adds information an agent needs; nothing is 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 2-optional-parameter lookup with no output schema, the description supplies purpose, result shape, ordering, field meanings, matching rules and cost. Nothing an agent needs in order to call and interpret this tool is missing.

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 goes further by explaining that matching is on English name fragments ('e.g. petersburg') and by clarifying canonical_name is the value the agent should pass onward. It doesn't restate the 1-10 limit bounds, but the schema already does.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Look up names for the location parameter') and explicitly ties it to sibling webscraping_ai_serp, so an agent knows this is the location-discovery companion to the SERP tool. It also enumerates the returned fields, making the output 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?

It names the sibling tool whose parameter it feeds and the workflow context, plus a real limitation ('Matches English names'), which effectively tells the agent when this will and won't work. It stops short of an explicit when-not/alternative rule, so not a full 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?

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description contributes useful output-shape context (Markdown, boilerplate removal, preserved structure) but says nothing about cost implications of proxies, failure modes, or what happens with the 14 behavioral knobs. It also asserts Markdown output while the schema's text_format defaults to 'json', an ambiguity left unresolved.

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 tight sentences plus a docs link; the output shape is front-loaded before the usage hint. 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 14-parameter, no-output-schema tool the description covers the primary return shape but omits how text_format (plain/xml/json, default json) changes the response and never mentions the cost-bearing proxy options or the JS/headless-browser path. Adequate to call the tool with just a URL, but thin for anything beyond the default 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% and parameter docs are detailed (proxy cost note, timeout max, CSS selector semantics), so the schema carries the burden. The description adds no parameter-level guidance of its own, which is the expected baseline here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get a web page's main content as Markdown') plus the transformation performed ('boilerplate stripped, structure... kept'), which contrasts implicitly with the raw-HTML sibling. It does not name the sibling (webscraping_ai_html) or any other alternative, so differentiation is inferable rather than explicit.

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?

'Best for reading a page or passing it to an LLM' gives a positive use case, but there is no exclusion or routing guidance versus the nine siblings (html, fields, selected, question, etc.). The agent must infer that this is the reading/LLM-context tool rather than the extraction tool.

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